This has actually been discovered as a problem on prefix install. Tags are small files providing syntax "highlighting" to emacs or vi. ecls currently automagically detects the etags program at configuration time. In a test on a prefix install an installation actually failed because a version of etags was detected outside of the prefix and ecls tried to use it. In that particular case etags was not provided by emacs but by ctags for vim (on a debian box) and it had an incompatible syntax: if test "xetags" != "x"; then \ srcfiles=`find /storage/strogdon/gentoo/var/tmp/portage/dev-lisp/ecls-11.1.1/work/ecl-11.1.1/src/c /storage/strogdon/gentoo/var/tmp/portage/dev-lisp/ecls-11.1.1/work/ecl-11.1.1/src/h -name '*.[chd]'` && \ etags --language=c -o TAGS $srcfiles && \ etags --language=none -o TAGS --append \ --regex='/@\([-:*a-zA-z]+\)/\1/' \ --regex='/@(defun \([-:*a-zA-z]+\)/\1/' \ $srcfiles; \ fi etags: Warning: "--language" option is obsolete; use "--language-force" instead etags: "TAGS" doesn't look like a tag file; I refuse to overwrite it. make[1]: *** [TAGS] Error 1 make[1]: Leaving directory `/storage/strogdon/gentoo/var/tmp/portage/dev-lisp/ecls-11.1.1/work/ecl-11.1.1/build' make: *** [all] Error 2 emake failed An elegant way of solving that particular problem is to put ecls in line with Gentoo policies against automagical detection and to control it by a use flag. This way we can make sure that tags are only generated when a gentoo dependency is satisfied. I am attaching an ebuild showing how to solve this particular problem with a minimal change to the sources.
Created attachment 264661 [details] ecls-11.1.1 ebuild solving the etags automagic detection problem There are several parts in the ebuild to deal with our present problem: 1) introduce "emacs" in IUSE since etags can be provided by other programs it could be changed. 2) add an "emacs" conditional dependency to virtual/emacs. In line with a previous comment it could also be to app-admin/eselect-ctags unless incompatibilities with ctags as provided by portage are discovered. 3) the ebuild is actually living in the sage-on-gentoo overlay and also includes the patch for #357315 sorry for the clutter. 4) I sed src/Makefile.in so that the TAGS target is not automatically build at compilation time. Because the build system doesn't actually use automake, we don't have to patch Makefile.am or use eautomake/eautoreconf and company. 5) in src_compile we produce tags normally if the proper useflag is on. Otherwise an empty file is produced. This mimicks what happens if etags is not found because the install target rely on there being a tag file (empty in the case where etags is not found).
(In reply to comment #1) > 1) introduce "emacs" in IUSE since etags can be provided by other programs > it could be changed. > 2) add an "emacs" conditional dependency to virtual/emacs. In line with > a previous comment it could also be to app-admin/eselect-ctags unless > incompatibilities with ctags as provided by portage are discovered. This won't work, because /usr/bin/etags could still be symlinked to exuberant-ctags (by "eselect etags") even if emacs is installed. Why not depend on "|| ( virtual/emacs dev-util/ctags )" and fix the error in the build system instead (see below). (In reply to comment #0) > etags: Warning: "--language" option is obsolete; use "--language-force" > instead Note that this is a warning only. (I've just verified that etags from exuberant-ctags still understands the --language option.) > etags: "TAGS" doesn't look like a tag file; I refuse to overwrite it. > make[1]: *** [TAGS] Error 1 Looks like this is the real error. For some reason there is a TAGS file already, and exuberant-ctags is picky about overwriting it (whereas etags from Emacs isn't).
(In reply to comment #2) > (In reply to comment #1) > > 1) introduce "emacs" in IUSE since etags can be provided by other programs > > it could be changed. > > 2) add an "emacs" conditional dependency to virtual/emacs. In line with > > a previous comment it could also be to app-admin/eselect-ctags unless > > incompatibilities with ctags as provided by portage are discovered. > > This won't work, because /usr/bin/etags could still be symlinked to > exuberant-ctags (by "eselect etags") even if emacs is installed. Why not depend > on "|| ( virtual/emacs dev-util/ctags )" and fix the error in the build system > instead (see below). I had a feeling something like that could happen. Just couldn't wrap my brain around it. > > (In reply to comment #0) > > etags: Warning: "--language" option is obsolete; use "--language-force" > > instead > > Note that this is a warning only. (I've just verified that etags from > exuberant-ctags still understands the --language option.) > > > etags: "TAGS" doesn't look like a tag file; I refuse to overwrite it. > > make[1]: *** [TAGS] Error 1 > > Looks like this is the real error. For some reason there is a TAGS file > already, and exuberant-ctags is picky about overwriting it (whereas etags from > Emacs isn't). > Interesting. I hadn't thought of that. The build system first create an empty file then calls etags if found. So it falls on its face all by itself if we have exuberant-ctags. The change will have to be more invasive and require more thought.
Created attachment 264793 [details, diff] patch the building system for exuberant ctags OK, could you try this patch. If this works properly I'll send this upstream. But we should still work around automagic detection. I can always ask upstream if they would be against making it a configurable option. That would make our work much easier (and could work out a patch for that as well but it is much more invasive).
Since it is not really an emacs problem, the useflag should probably be tags instead. That will mean changing metadata.xml since there are currently no flags for this particular case (in vim ctags is pulled by "-minimal"). The other solution would be to add the patch and leave the automagic go on.
Actually ecls is checking for "etags". In portage exubherant-ctags provides only "ctags" and not "etags" so my first solution seems to stand. It looks like debian is doing something weird by linking etags to ctags.
(In reply to comment #5) > Since it is not really an emacs problem, the useflag should probably be tags > instead. That will mean changing metadata.xml since there are currently no > flags for this particular case (in vim ctags is pulled by "-minimal"). The package only installs Emacs tags (uppercase "TAGS" file, while the vi tags file would be called "tags" in lowercase). So your first idea with the emacs USE flag wasn't so wrong. Probably it's a matter of taste, but I would go with the emacs flag, instead of introducing a new local USE flag that would control installation of a single file. > The other solution would be to add the patch and leave the automagic go on. That's against our policy. (In reply to comment #6) > Actually ecls is checking for "etags". In portage exubherant-ctags provides > only "ctags" and not "etags" so my first solution seems to stand. # eselect etags list Available etags symlink targets: [1] etags-emacs-24 * [2] exuberant-ctags # eselect etags set 2 Switching etags to exuberant-ctags ... # ls -l /usr/bin/etags lrwxrwxrwx 1 root root 15 Mar 6 12:45 /usr/bin/etags -> exuberant-ctags
(In reply to comment #6) > Actually ecls is checking for "etags". In portage exubherant-ctags provides > only "ctags" and not "etags" so my first solution seems to stand. It looks like > debian is doing something weird by linking etags to ctags. > I thought I'd comment since I have a debian box with prefix installed. Yes etags is symlinked in several stages to their exuberant-ctags; not unlike eselect etags set exuberant-ctags I does seem that ecls is oriented toward emacs/etags and not ctags. Now the "automagic" stuff is a potential "problem", even from a native gentoo install; at least if ctags is allowed. With the ecls-11.1.1-ctags.patch and etags set to exuberant-ctags a build of ecls with tags gives if test "xetags" != "x"; then \ srcfiles=`find /var/tmp/portage/dev-lisp/ecls-11.1.1-r1/work/ecl-11.1.1/src/c /var/tmp/portage/dev-lisp/ecls-11.1.1-r1/work/ecl-11.1.1/src/h -name '*.[chd]'` && \ etags --language=c -o TAGS $srcfiles && \ etags --language=none -o TAGS --append \ --regex='/@\([-:*a-zA-z]+\)/\1/' \ --regex='/@(defun \([-:*a-zA-z]+\)/\1/' \ $srcfiles; \ fi etags: Warning: "--language" option is obsolete; use "--language-force" instead etags: Warning: "--language" option is obsolete; use "--language-force" instead etags: Unknown language "none" in "language" option make: *** [TAGS] Error 1 emake failed and the TAGS file is generated but not with the etags it was expecting. So it may be that if the emacs USE flag is used with the intended etags then the ebuild must make sure that etags is selected to etags-emacs-XX. Is this even possible?
I guess I only tested with dev-utils/ctags installed so I didn't see etags in eselect. Thanks for doing that further testing Steve. That is turning to be quite a headache. So with my patch and ctags' etags you get another error. I will report this upstream so they can ponder about it as well. If virtual/emacs pulls eselect-ctags we could leave the sole dependency on emacs and eselect the emacs etags from the ebuild and restore the initial setting at the end of the build. How does that sound?
(In reply to comment #9) > That is turning to be quite a headache. So with my patch and ctags' etags > you get another error. Right, with your patch, the first etags will now succeed, but the second one (with --language=none) will fail. (And I've missed that too.) > I will report this upstream so they can ponder about it as well. Please do. It's an issue that upstream should be aware of. There are at least two distros where etags can be linked to (exuberant-) ctags. BTW, there's a third possibility: etags could be symlinked to etags from XEmacs. But looks like this one understands the same options as etags from GNU Emacs. > If virtual/emacs pulls eselect-ctags we could leave the sole dependency on > emacs and eselect the emacs etags from the ebuild and restore the initial > setting at the end of the build. How does that sound? That won't work. You cannot change the etags symlink in src_compile (or in any other src_* phase) because it is sandboxed. Besides, if the build fails, the live system would be left with a changed setting. A possible workaround is to add the following line at the beginning of src_compile: ( cd build; emake TAGS ) This at least makes the build succeed. Of course, it doesn't fix the problem of automagic detection.
(In reply to comment #10) > (In reply to comment #9) > > That is turning to be quite a headache. So with my patch and ctags' etags > > you get another error. > > Right, with your patch, the first etags will now succeed, but the second one > (with --language=none) will fail. (And I've missed that too.) > That makes my second patch moot since we really want an {X}emacs etags in the end. > > I will report this upstream so they can ponder about it as well. > > Please do. It's an issue that upstream should be aware of. There are at least > two distros where etags can be linked to (exuberant-) ctags. > Will do and post a link to it here. > BTW, there's a third possibility: etags could be symlinked to etags from > XEmacs. But looks like this one understands the same options as etags from GNU > Emacs. > > > If virtual/emacs pulls eselect-ctags we could leave the sole dependency on > > emacs and eselect the emacs etags from the ebuild and restore the initial > > setting at the end of the build. How does that sound? > > That won't work. You cannot change the etags symlink in src_compile (or in any > other src_* phase) because it is sandboxed. Besides, if the build fails, the > live system would be left with a changed setting. > That's why you do it in pkg_setup and pkg_postinst. xorg-server was doing it (see x11-base/xorg-server-1.7.7-r1). The only problem is to remove the first line of eselect etags show to have something we can reuse. This is very hackish. > A possible workaround is to add the following line at the beginning of > src_compile: > > ( cd build; emake TAGS ) > > This at least makes the build succeed. Not sure I get this.
Created attachment 265033 [details, diff] patch for ecls-11.1.1-r1.ebuild (In reply to comment #11) > > That won't work. You cannot change the etags symlink in src_compile (or > > in any other src_* phase) because it is sandboxed. Besides, if the build > > fails, the live system would be left with a changed setting. > > That's why you do it in pkg_setup and pkg_postinst. No. An ebuild really shouldn't modify the live system like this. Think of binary packages, where both of these phase function are called. Besides, there will still be the above-mentioned issue when the build fails, and if you think of parallel builds (emerge --jobs) it becomes a nightmare. If xorg-server did such things then it was very wrong, IMHO. But could you please test if attached patch for the ebuild fixes the problem?
(In reply to comment #12) > Created attachment 265033 [details, diff] > patch for ecls-11.1.1-r1.ebuild > > (In reply to comment #11) > > > That won't work. You cannot change the etags symlink in src_compile (or > > > in any other src_* phase) because it is sandboxed. Besides, if the build > > > fails, the live system would be left with a changed setting. > > > > That's why you do it in pkg_setup and pkg_postinst. > > No. An ebuild really shouldn't modify the live system like this. Think of > binary packages, where both of these phase function are called. Besides, there > will still be the above-mentioned issue when the build fails, and if you think > of parallel builds (emerge --jobs) it becomes a nightmare. If xorg-server did > such things then it was very wrong, IMHO. > > But could you please test if attached patch for the ebuild fixes the problem? François should give the definitive answer, but the patch works here in both prefix and in a native gentoo install.
I was in the process of putting it in the overlay for you to test Steve. I personally like the fix. It teaches me a bit of new eselect hackery (where is "--brief" documented?) and some nice sed you have there. The only thing I don't know for sure because I haven't completely parsed the sed command command yet is what happens if you have several emacs installed, either several slots or emacs/xemacs. Provided that in that case we have a nice unique command, it looks good to me. Now off to sourceforge to finally fill that bug.
Added the URL for upstream bug in sourceforge
Very clever system you have there in eselect etags and emacs. So there is only ever one version of emacs etags to select at any one time and exuberant-ctags if it is installed. It works for me and I don't see any further problems with this. Now I will have to mop up all these emacs install from my system.
I've committed the fix. No revbump, because it's a build problem. (And for people using emerge --newuse the package will be rebuilt anyway.) Thanks François and Steven.
