Bug 242176

Created attachment 156563 [details]
Add pkgconfig file for emacs

How about this (untested) spec file patch?

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

(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

(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 :)

Created attachment 156577 [details]
Patch spec file to add pkf-config entry

Updated to reflect Ville's comments.

Created attachment 156578 [details]
Patch spec file to add pkg-config file (take 3)

Better use of %{site_lisp} macro for consistency

(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

> 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.

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.

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.

(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. 

(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

(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

(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.

(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

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.

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.

patch included in 22.1-2.

Excellent, thanks very much. Are you pushing this for F7 as well as rawhide?

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.

This is now resolved (thanks!), so closing bug.