Bug 242176 - RFE: add pkgconfig file for emacs-common
RFE: add pkgconfig file for emacs-common
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: emacs (Show other bugs)
7
All Linux
medium Severity medium
: ---
: ---
Assigned To: Chip Coldwell
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-01 19:39 EDT by Jonathan Underwood
Modified: 2007-11-30 17:12 EST (History)
1 user (show)

See Also:
Fixed In Version: 22.1-2
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-11-25 20:28:24 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Add pkgconfig file for emacs (1.40 KB, patch)
2007-06-08 06:41 EDT, Jonathan Underwood
no flags Details | Diff
Patch spec file to add pkf-config entry (1.59 KB, text/x-patch)
2007-06-08 10:48 EDT, Jonathan Underwood
no flags Details
Patch spec file to add pkg-config file (take 3) (1.56 KB, patch)
2007-06-08 10:53 EDT, Jonathan Underwood
no flags Details | Diff
Add pkgconfig file and virtual provides emacs (bin) (1.56 KB, patch)
2007-07-29 09:43 EDT, Jonathan Underwood
no flags Details | Diff

  None (edit)
Description Jonathan Underwood 2007-06-01 19:39:15 EDT
Description of problem:
Currently there is no reliable way for emacs add on packages to detect which
emacs version they were built with. This is desireable because add-on's really
need to have Requires: emacs >= X.Y  where X.Y is the build time version of Emacs.

Following a lengthy discussion on the packagers list, Ville came up with what I
think is a great suggestion - to have both Emacs and XEmacs include a pkgconfig
file. The one that Ville suggested for XEmacs is:

prefix=/usr
includedir=/usr/lib64/xemacs-21.5-b28/x86_64-redhat-linux/include
sitestartdir=/usr/share/xemacs/site-packages/lisp/site-start.d
sitepkglispdir=/usr/share/xemacs/site-packages/lisp
sitemoduledir=/usr/lib64/xemacs/site-modules

Name: xemacs
Description: Different version of Emacs
Version: 21.5.28
Cflags: -I${includedir}

which then allows things like:

$ pkg-config xemacs --modversion
21.5.28
$ pkg-config xemacs --variable=sitestartdir
/usr/share/xemacs/site-packages/lisp/site-start.d
$ pkg-config xemacs --variable=sitepkglispdir
/usr/share/xemacs/site-packages/lisp
$ pkg-config xemacs --variable=sitemoduledir
/usr/lib64/xemacs/site-modules
$ pkg-config xemacs --cflags
-I/usr/lib64/xemacs-21.5-b28/x86_64-redhat-linux/include

to be done when building add-ons.

If we could standardize the approach across Emacs and XEmacs, that would be
superb. I have cc'd Ville.

I think we need to resolve this before finalizing the Emacsen add-ons packaging
guidelines.
Comment 1 Jonathan Underwood 2007-06-08 06:41:29 EDT
Created attachment 156563 [details]
Add pkgconfig file for emacs

How about this (untested) spec file patch?
Comment 2 Ville Skyttä 2007-06-08 09:53:36 EDT
Untested, but some comments:

- A dependency on pkgconfig should be added.  Even better if a -devel subpackage
would be split off the main one and the dependency added to it, but perhaps only
if there's other Emacs development related stuff currently included in the main
package.

- The pkgconfig file should use the same macros as the rest of the specfile
instead of hardcoding paths of its own.

- Perhaps add prefix=%{_prefix}?

For reference, here's what I did in the xemacs package (contains non-pkgconfig
related changes too):
http://cvs.fedora.redhat.com/viewcvs/devel/xemacs/xemacs.spec?root=extras&r1=1.35&r2=1.36&makepatch=1&diff_format=h
Comment 3 Chip Coldwell 2007-06-08 10:13:54 EDT
(In reply to comment #2)
> Untested, but some comments:
> 
> - A dependency on pkgconfig should be added.  Even better if a -devel subpackage
> would be split off the main one and the dependency added to it, but perhaps only
> if there's other Emacs development related stuff currently included in the main
> package.

emacs-el?

Chip
Comment 4 Jonathan Underwood 2007-06-08 10:41:46 EDT
(In reply to comment #3)
> (In reply to comment #2)
> > Untested, but some comments:
> > 
> > - A dependency on pkgconfig should be added.  Even better if a -devel subpackage
> > would be split off the main one and the dependency added to it, but perhaps only
> > if there's other Emacs development related stuff currently included in the main
> > package.
> 
> emacs-el?

No, that wouldn't work - it's very rare for an add-on package to need to have
emacs-el installed in the buildroot to build the package.

It makes sense to have it in the emacs-common package to me, or an
emacs-common-devel package as Ville suggested. But a seperte devel package for
one file seems a bit excessive :)
Comment 5 Jonathan Underwood 2007-06-08 10:48:37 EDT
Created attachment 156577 [details]
Patch spec file to add pkf-config entry

Updated to reflect Ville's comments.
Comment 6 Jonathan Underwood 2007-06-08 10:53:19 EDT
Created attachment 156578 [details]
Patch spec file to add pkg-config file (take 3)

Better use of %{site_lisp} macro for consistency
Comment 7 Chip Coldwell 2007-06-08 11:20:39 EDT
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > Untested, but some comments:
> > > 
> > > - A dependency on pkgconfig should be added.  Even better if a -devel
subpackage
> > > would be split off the main one and the dependency added to it, but
perhaps only
> > > if there's other Emacs development related stuff currently included in the
main
> > > package.
> > 
> > emacs-el?
> 
> No, that wouldn't work - it's very rare for an add-on package to need to have
> emacs-el installed in the buildroot to build the package.
> 
> It makes sense to have it in the emacs-common package to me, or an
> emacs-common-devel package as Ville suggested. But a seperte devel package for
> one file seems a bit excessive :)

What I meant was, put the contents of emacs-el into emacs-devel, along with the
pkgconfig.

Chip


Comment 8 Jonathan Underwood 2007-06-08 11:33:38 EDT
> What I meant was, put the contents of emacs-el into emacs-devel, along with the
> pkgconfig.

Interesting idea. Initial thoughts:

a) the purpose of emacs.pc is to allow add on packages to be built against
emacs, and so it is a "development" file. I guess this is why you'd rather not
have it in emacs-common - a fair point.

b) building add-on packages rarely if ever requires the emacs-el elisp sources.
That's not true of some add-on packages though (eg. bbdb needs vm source elisp
to build).

I can see the attractions of bundling them together - there's very little point
to having emacs.pc bundled in a non-development package as far as a non-package
builder is concerned.

Current add on package nameing guidelines mandate calling the subpackage
containing elisp source emacs-foo-el, based on the precedent set by emacs.

I do prefer -devel to -el. Question is, is now the right time to make such a change.


Comment 9 Jonathan Underwood 2007-06-15 07:11:01 EDT
Hi Chip & Ville,

It would be really useful to make progress on this so we can finalize the
packaging guidelines for (X)Emacs add-ons.

The question seems to be "Which package should emacs.pc be placed in". 

Argument against emacs-common: it is not required for normal emacs usage, only
package building.

Argument against emacs-el: building add-on packages for (X)Emacs rarely (if
ever?) requires the elisp source.


I am much more in favour of placing it in emacs-el and xemacs-el, though.

Second question: should (x)emacs-el be renamed (x)emacs-devel?

For: more consistency with other packaging
Against: the -el precedent is already widely adopted for add-ons.

Pragmatically, I'd go for putting emacs.pc in emacs-el and leaving the second
question alone for now, as it's rather cosmetic.
Comment 10 Ville Skyttä 2007-06-15 12:10:56 EDT
I've already added the pkgconfig file to latest FC6+ xemacs-deve-21.5.28-2.fc*
packages.  XEmacs actually does have a useful -devel package, primarily
containing stuff (header files, ellcc) that is required to build XEmacs modules.

If Emacs doesn't have a "natural" -devel subpackage and adding one with just the
pkgconfig file feels overkill, if it was my call, I'd probably go for adding it
to -el and adding "Provides: %{name}-devel = %{version}-%{release}" to -el too,
and then using emacs-devel in the add-on guidelines.
Comment 11 Jonathan Underwood 2007-06-15 12:18:42 EDT
(In reply to comment #10)
> I've already added the pkgconfig file to latest FC6+ xemacs-deve-21.5.28-2.fc*
> packages.  XEmacs actually does have a useful -devel package, primarily
> containing stuff (header files, ellcc) that is required to build XEmacs modules.
> 

Brilliant, thanks!

> If Emacs doesn't have a "natural" -devel subpackage and adding one with just the
> pkgconfig file feels overkill, if it was my call, I'd probably go for adding it
> to -el and adding "Provides: %{name}-devel = %{version}-%{release}" to -el too,
> and then using emacs-devel in the add-on guidelines.

Yes! Great suggestion, I like that a lot. 
Comment 12 Chip Coldwell 2007-06-26 14:20:13 EDT
(In reply to comment #0)
> Description of problem:
> Currently there is no reliable way for emacs add on packages to detect which
> emacs version they were built with. This is desireable because add-on's really
> need to have Requires: emacs >= X.Y  where X.Y is the build time version of Emacs.
> 
> Following a lengthy discussion on the packagers list, Ville came up with what I
> think is a great suggestion - to have both Emacs and XEmacs include a pkgconfig
> file. The one that Ville suggested for XEmacs is:
> 
> prefix=/usr
> includedir=/usr/lib64/xemacs-21.5-b28/x86_64-redhat-linux/include
> sitestartdir=/usr/share/xemacs/site-packages/lisp/site-start.d
> sitepkglispdir=/usr/share/xemacs/site-packages/lisp
> sitemoduledir=/usr/lib64/xemacs/site-modules

This is clearly wrong, isn't it?  Why are you hard-coding /usr/lib64?  What
happens on 32-bit architectures?

Chip

Comment 13 Chip Coldwell 2007-06-26 14:26:57 EDT
(In reply to comment #0)
> Description of problem:
> Currently there is no reliable way for emacs add on packages to detect which
> emacs version they were built with. This is desireable because add-on's really
> need to have Requires: emacs >= X.Y  where X.Y is the build time version of Emacs.
> 
> Following a lengthy discussion on the packagers list, Ville came up with what I
> think is a great suggestion - to have both Emacs and XEmacs include a pkgconfig
> file. The one that Ville suggested for XEmacs is:
> 
> prefix=/usr
> includedir=/usr/lib64/xemacs-21.5-b28/x86_64-redhat-linux/include
> sitestartdir=/usr/share/xemacs/site-packages/lisp/site-start.d
> sitepkglispdir=/usr/share/xemacs/site-packages/lisp
> sitemoduledir=/usr/lib64/xemacs/site-modules
> 
> Name: xemacs
> Description: Different version of Emacs
> Version: 21.5.28
> Cflags: -I${includedir}
> 
> which then allows things like:

Actually, the GNU emacs version of this would be nearly trivial:

> $ pkg-config xemacs --modversion
> 21.5.28

22.1

> $ pkg-config xemacs --variable=sitestartdir
> /usr/share/xemacs/site-packages/lisp/site-start.d

/usr/share/emacs/site-lisp/site-start.d

> $ pkg-config xemacs --variable=sitepkglispdir
> /usr/share/xemacs/site-packages/lisp

doesn't exist

> $ pkg-config xemacs --variable=sitemoduledir
> /usr/lib64/xemacs/site-modules

doesn't exist

> $ pkg-config xemacs --cflags
> -I/usr/lib64/xemacs-21.5-b28/x86_64-redhat-linux/include

doesn't exist

> to be done when building add-ons.

What languages are these add-ons written in?  Can you give me an example of one?

Chip
Comment 14 Ville Skyttä 2007-06-26 15:28:40 EDT
(In reply to comment #12)
> This is clearly wrong, isn't it?  Why are you hard-coding /usr/lib64?

I'm not, it's just an example of what it would look like on 64-bit archs.  The
actual file is emitted from the specfile during build, and uses macros, see
xemacs/devel/xemacs.spec in CVS or the link in comment 2.

(In reply to comment #13)
> (In reply to comment #0)
> 
> > $ pkg-config xemacs --variable=sitepkglispdir
> > /usr/share/xemacs/site-packages/lisp
> 
> doesn't exist

This dir is intended to denote the location where installed elisp add-on
packages should drop their own subdir.  XEmacs has differing concepts of add-on
site lisp *package* directories and plain old site-lisp directories, that's why
I named it site*pkg*lispdir.  I gather GNU Emacs doesn't have that distinction
and the correct location for it for this purpose would be
/usr/share/emacs/site-lisp, no matter whether the variable is named
sitepkglispdir or sitelispdir or something else.  sitepkglispdir would be
consistent with XEmacs and thus possibly easier for packagers.

> What languages are these add-ons written in?

Plain old Emacs lisp.  Eg. psgml, other emacs-* add-on packages in Fedora.
Comment 15 Chip Coldwell 2007-06-26 16:13:41 EDT
(In reply to comment #14)
> (In reply to comment #12)
> > This is clearly wrong, isn't it?  Why are you hard-coding /usr/lib64?
> 
> I'm not, it's just an example of what it would look like on 64-bit archs.  The
> actual file is emitted from the specfile during build, and uses macros, see
> xemacs/devel/xemacs.spec in CVS or the link in comment 2.

Ah, I see.

> > > $ pkg-config xemacs --variable=sitepkglispdir
> > > /usr/share/xemacs/site-packages/lisp
> > 
> > doesn't exist
> 
> This dir is intended to denote the location where installed elisp add-on
> packages should drop their own subdir.  XEmacs has differing concepts of add-on
> site lisp *package* directories and plain old site-lisp directories, that's why
> I named it site*pkg*lispdir.  I gather GNU Emacs doesn't have that distinction
> and the correct location for it for this purpose would be
> /usr/share/emacs/site-lisp, no matter whether the variable is named
> sitepkglispdir or sitelispdir or something else.  sitepkglispdir would be
> consistent with XEmacs and thus possibly easier for packagers.

OK.

Chip
Comment 16 Jonathan Underwood 2007-07-29 09:40:13 EDT
Hi Chip,

This bug has been languishing a while now and is blocking the publication of the
emacs packaging guidelines. Please would you consider the patch I will attach in
the next comment.
Comment 17 Jonathan Underwood 2007-07-29 09:43:05 EDT
Created attachment 160190 [details]
Add pkgconfig file and virtual provides emacs (bin)

This patch adds a minimal pkgconfig file into the emacs-el sub-package. It also
add Provides: emacs(bin) to the emacs and emacs-nox packages. Both these
changes make it much easier to reliably package add-on packages for Emacs and
will allow us to push ahead with the Emacs package add-on guidelines. This
patch also fixes BZ #239374.
Comment 18 Chip Coldwell 2007-08-14 11:55:59 EDT
patch included in 22.1-2.
Comment 19 Jonathan Underwood 2007-08-14 11:58:56 EDT
Excellent, thanks very much. Are you pushing this for F7 as well as rawhide?
Comment 20 Jonathan Underwood 2007-09-06 18:08:31 EDT
Hi Chip - any chance of pushing a build for F-7 with this patch applied. With
the Emacs add-on packaging guideline now "official" it would help *a lot* with
package maintainence to have the F-7 and F-8 emacs packages consistent.
Comment 21 Jonathan Underwood 2007-11-25 20:28:24 EST
This is now resolved (thanks!), so closing bug.

Note You need to log in before you can comment on or make changes to this bug.