I have a personal version of emacs-cvs-23.0.93.ebuild with the new cocoa feature enabled instead of the old carbon framework. The feature should be enabled with USE='aqua' ideally, but it is disabled by package.use.mask in the darwin/macos profile. So, please unmask the USE flag, if my ebuild file, or some similar attempt, will be in the prefix tree. I know the 23.0.9999 ebuild still maintains the code to build carbon emacs, but it should be replaced similarly. The ebuild file follows.
Created attachment 190476 [details] cocoa enabled 23.0.93 ebuild There are some hackish parts in the ebuild. 1. USE=cocoa is chosen temporarily instead of 'aqua'. 2. Emacs.app installation steps have just working-for-me quality.
(In reply to comment #1) > Created an attachment (id=190476) [edit] > cocoa enabled 23.0.93 ebuild > > There are some hackish parts in the ebuild. > > 1. USE=cocoa is chosen temporarily instead of 'aqua'. > 2. Emacs.app installation steps have just working-for-me quality. > please provide diff -u so we can properly evaluate this without too much time.
It is not worth spending time on this bug for now, and I would not take time to produce diff for you. Reasons: 1) I realized that emacs-cvs is too unstable for daily work. 2) 23.0.93 is not the latest already. 3) Murphy's law: if I provide an entire ebuild, gentoo developers request me a diff, but if I provide diff ... I got tired.
Created attachment 198246 [details, diff] diff against ecopied 23.0.96 Now I'm back to emacs-cvs and happy with its greatly improved stability. This time, I post my ebuild as a patch.
Basically this looks sane, although I cannot evaluate all parts of the "hackish" lines.
After discussion with my fellow Emacs team mate ulm about the patch we think that the patch needs some love. Details will follow soon.
(In reply to comment #4) > Created an attachment (id=198246) [details] > diff against ecopied 23.0.96 Thank you for the patch. Please allow me some comments and questions: + if use X && use cocoa; then + die "the X and cocoa USE-flags cannot be used together, please use one" + fi Our policy on conflicting USE flags is specified in the devmanual: # Occasionally, ebuilds will have conflicting USE flags for functionality. # Checking for them and returning an error is not a viable solution. # Instead, you must pick one of the USE flags in conflict to favour. So the whole if statement should just be removed. The logic below just works fine in case the user has specified both flags. + myconf="${myconf} --without-ns" Not necessary since --without-ns is the default (and otherwise it should be added to the "use X" case too, for consistency). This is a minor point though. + # very hackish :( + if use cocoa; then + sed -i "s%^\(#define PATH_EXEC\).*%\1 \"${EPREFIX}/usr/libexec/emacs/${PV}/${CHOST}\"%" \ + src/epaths.h || die "PATH_EXEC editing failed" + fi I don't understand why this is necessary. PATH_EXEC is initialised from archlibdir, which in turn is initialised by configure as: archlibdir='${libexecdir}/emacs/${version}/${configuration}' What am I missing here? + # to avoid accidental removal of everything + if use cocoa; then + make install-arch-dep + fi "install-arch-dep" is a prerequisite of "install", so why is this needed? + emake install DESTDIR="${D}" exec_prefix="${EPREFIX}/usr" \ + libexecdir="${EPREFIX}/usr/libexec" \ Again, exec_prefix and libexecdir should already have been initialised at configure time. If not, then it is a bug in the (upstream) build system that should be reported upstream. + if [ -e "${ED}"usr/bin/emacs-${FULL_VERSION}-${EMACS_SUFFIX} ]; This test should never evaluate to false. (If it did, it would mean that there is no Emacs binary and then the ebuild should die. Which the following mv command does.) + if [ ! -e "${ED}"/Applications/Gentoo ]; then + mkdir -p "${ED}"/Applications/Gentoo + fi + mv "${S}"/nextstep/Emacs.app "${ED}"/Applications/Gentoo/Emacs-${FULL_VERSION}.app "insinto" and "newins" are your friends here.
Thank you for your detailed comments. I try to recall my guesses as far as I can. (In reply to comment #7) > + if use X && use cocoa; then > + die "the X and cocoa USE-flags cannot be used together, please use one" > + fi > > Our policy on conflicting USE flags is specified in the devmanual: > # Occasionally, ebuilds will have conflicting USE flags for functionality. > # Checking for them and returning an error is not a viable solution. > # Instead, you must pick one of the USE flags in conflict to favour. I'm not a dev and haven't seen the devmanual (where is it?), but it's ok to remove such part according to the policy. > So the whole if statement should just be removed. The logic below just works > fine in case the user has specified both flags. > > + myconf="${myconf} --without-ns" > > Not necessary since --without-ns is the default (and otherwise it should be > added to the "use X" case too, for consistency). This is a minor point though. OK. > + # very hackish :( > + if use cocoa; then > + sed -i "s%^\(#define PATH_EXEC\).*%\1 > \"${EPREFIX}/usr/libexec/emacs/${PV}/${CHOST}\"%" \ > + src/epaths.h || die "PATH_EXEC editing failed" > + fi > > I don't understand why this is necessary. PATH_EXEC is initialised from > archlibdir, which in turn is initialised by configure as: > archlibdir='${libexecdir}/emacs/${version}/${configuration}' > > What am I missing here? Well, without that hack, archlibdir wasn't such a useful path and you would have encountered a warning: Warning: arch-dependent data dir (/dir/you/are/compiling/nextstep/Emacs.app/Contents/MacOS/libexec/emacs/23.0.96/i686-apple-darwin9/) does not exist. I couldn't find a way to configure to avoid such a problem. > + # to avoid accidental removal of everything > + if use cocoa; then > + make install-arch-dep > + fi > > "install-arch-dep" is a prerequisite of "install", so why is this needed? Because, without it, everything disappears during compilation! I'm not joking. There remains almost empty directory. > + emake install DESTDIR="${D}" exec_prefix="${EPREFIX}/usr" \ > + libexecdir="${EPREFIX}/usr/libexec" \ > > Again, exec_prefix and libexecdir should already have been initialised at > configure time. If not, then it is a bug in the (upstream) build system that > should be reported upstream. exec_prefix part was needed to put emacs binaries into ${EPREFIX}/usr/bin. libexecdir was completely useless, as far as I remember. > + if [ -e "${ED}"usr/bin/emacs-${FULL_VERSION}-${EMACS_SUFFIX} ]; > > This test should never evaluate to false. (If it did, it would mean that there > is no Emacs binary and then the ebuild should die. Which the following mv > command does.) Is it so? The message suggest that there were emacs-23.0.96-emacs-23 and emacs-emacs-23. # ... uh, then without such versions no mv? Sorry, something might be broken in this part. > + if [ ! -e "${ED}"/Applications/Gentoo ]; then > + mkdir -p "${ED}"/Applications/Gentoo > + fi > + mv "${S}"/nextstep/Emacs.app > "${ED}"/Applications/Gentoo/Emacs-${FULL_VERSION}.app > > "insinto" and "newins" are your friends here. You're right. Summary: The --with-ns option strongly assumes the directory structure it use. The assumption conflicts with Gentoo's way of compiling packages. I don't know it should be called bug or not. PS: There is another concern with this issue: how eselect-emacs to handle the Emacs.app. Probably, no one has tackled.
(In reply to comment #8) > I'm not a dev and haven't seen the devmanual (where is it?), http://devmanual.gentoo.org/ > but it's ok to remove such part according to the policy. On second thought, we could display a warning if both flags are set (as we do for gtk/Xaw3d/motif USE flags). > Well, without that hack, archlibdir wasn't such a useful path and you would > have encountered a warning: > Warning: arch-dependent data dir > (/dir/you/are/compiling/nextstep/Emacs.app/Contents/MacOS/libexec/emacs/23.0.96/i686-apple-darwin9/) > does not exist. Hm, I think I've found the problem in configure.in: if test "${HAVE_NS}" = yes; then # [...] # set up packaging dirs exec_prefix=${ns_appbindir} libexecdir=${ns_appbindir}/libexec if test "${EN_NS_SELF_CONTAINED}" = yes; then prefix=${ns_appresdir} fi fi Which overrides any libexecdir and exec_prefix explicitly specified by the user, so it is a bug that should be reported upstream. We can locally patch configure.in in the mean time (just move the two lines down, into the second if statement). > > + # to avoid accidental removal of everything > > + if use cocoa; then > > + make install-arch-dep > > + fi > > > > "install-arch-dep" is a prerequisite of "install", so why is this needed? > Because, without it, everything disappears during compilation! > I'm not joking. There remains almost empty directory. Another upstream bug? Does it still happen if you add "-j1" to "emake install"? > exec_prefix part was needed to put emacs binaries into ${EPREFIX}/usr/bin. > libexecdir was completely useless, as far as I remember. See above, this should no longer be an issue if configure is fixed. > Is it so? The message suggest that there were > emacs-23.0.96-emacs-23 and emacs-emacs-23. Yes, the Makefile installs it under both names. > Summary: > The --with-ns option strongly assumes the directory structure it use. > The assumption conflicts with Gentoo's way of compiling packages. > I don't know it should be called bug or not. Call it a bug. The point is that paths explicitly specified as configure options are overridden. Could you report this issue upstream please? > PS: There is another concern with this issue: how eselect-emacs to handle the > Emacs.app. Probably, no one has tackled. It shouldn't be such a problem to add support to the eselect module. But I would need help with the installation paths. From the einfo message I conclude that the ebuild should install the file in ${EROOT}/Applications/Emacs-${EMACS_SUFFIX}.app and eselect should set a symlink in ${ROOT}/Applications/Emacs.app. Is this right?
(In reply to comment #9) > > Well, without that hack, archlibdir wasn't such a useful path and you would > > have encountered a warning: > > Warning: arch-dependent data dir > > (/dir/you/are/compiling/nextstep/Emacs.app/Contents/MacOS/libexec/emacs/23.0.96/i686-apple-darwin9/) > > does not exist. > > Hm, I think I've found the problem in configure.in: > > if test "${HAVE_NS}" = yes; then > # [...] > # set up packaging dirs > exec_prefix=${ns_appbindir} > libexecdir=${ns_appbindir}/libexec > if test "${EN_NS_SELF_CONTAINED}" = yes; then > prefix=${ns_appresdir} > fi > fi > > Which overrides any libexecdir and exec_prefix explicitly specified by the > user, so it is a bug that should be reported upstream. > We can locally patch configure.in in the mean time (just move the two lines > down, into the second if statement). This may not be so much an upstream bug, but more a mismatch to what we (Gentoo Prefix on OSX team) want and what upstream wants. Normally, if you build an .app, you put everything inside it, such that it becomes a standalone app. However, I prefer to have the .app next to a traditional UNIX install. That means, just an emacs binary, and all support files in the same place as without .app. The .app is then installed next to that, preferably reusing stuff from the UNIX install. I assume upstream wants to build the .app and only the .app if you ask for that. I'm not sure how emacs 22.3.1 did this which I have installed here with Carbon interface. It is installed like I described AFAICT.
(In reply to comment #10) > This may not be so much an upstream bug, but more a mismatch to what we > (Gentoo Prefix on OSX team) want and what upstream wants. But still, they should respect explicitly given --exec-prefix and --libexecdir options. That's what configure is for, isn't it?
If you have contacts with upstream, talk to them to figure out what they think. It is questionable to me if there's anything "right" when .apps are generated out of autoconf code. I prefer it over an Xcode build, but it's two different worlds IMO.
(In reply to comment #9) > (In reply to comment #8) > > I'm not a dev and haven't seen the devmanual (where is it?), > > http://devmanual.gentoo.org/ Thanks, I'll take a look. > > > + # to avoid accidental removal of everything > > > + if use cocoa; then > > > + make install-arch-dep > > > + fi > > > > > > "install-arch-dep" is a prerequisite of "install", so why is this needed? > > > Because, without it, everything disappears during compilation! > > I'm not joking. There remains almost empty directory. > > Another upstream bug? Does it still happen if you add "-j1" to "emake install"? Commenting out the part gives you (with MAKEOPTS=-j1): make: *** No rule to make target `leim/Makefile', needed by `install-leim'. Stop. and then: % cd $EPREFIX/var/tmp/portage/app-editors/emacs-23.1/work/emacs-23.1/ % ls -l total 4 lrwxr-xr-x 1 tetsushi tetsushi 12 Nov 26 20:38 * -> ../libexec/* % This is a bug (I hoped to be fixed in 23.1 but was not). > > PS: There is another concern with this issue: how eselect-emacs to handle the > > Emacs.app. Probably, no one has tackled. > > It shouldn't be such a problem to add support to the eselect module. But I > would need help with the installation paths. From the einfo message I conclude > that the ebuild should install the file in > ${EROOT}/Applications/Emacs-${EMACS_SUFFIX}.app and eselect should set a > symlink in ${ROOT}/Applications/Emacs.app. Is this right? OS X's launcher for .app applications (open -a) doesn't understand symlink. So, you have to copy or hard link it. Another point is that /Applications (or ~/Applications) is outside the $EPREFIX/ directory. I think prefix's policy does not allow manipulation outside $EPREFIX/ in principle.
(In reply to comment #13) > Commenting out the part gives you (with MAKEOPTS=-j1): > make: *** No rule to make target `leim/Makefile', needed by `install-leim'. > Stop. Can you attach the full log for this? > This is a bug (I hoped to be fixed in 23.1 but was not). Yes, and we should do something so that it will be fixed in 23.2. > OS X's launcher for .app applications (open -a) doesn't understand symlink. > So, you have to copy or hard link it. > Another point is that /Applications (or ~/Applications) is outside the > $EPREFIX/ directory. I think prefix's policy does not allow manipulation > outside $EPREFIX/ in principle. So there's really nothing that eselect could do here.
Created attachment 211254 [details] faillog log w/o make install-arch-dep, failed as comment 13.
(In reply to comment #15) > Created an attachment (id=211254) [details] > faillog Thanks for the log. It fails for install-arch-dep, namely here: if test "${ns_appdir}" != ""; then \ ( cd ${ns_appresdir} ; \ if test -d share/emacs ; then dir=share/emacs/*/*; $(MV_DIRS); fi;\ if test -d share/info ; then dir=share/info; $(MV_DIRS) ; fi ; \ rm -fr share ) ; \ ( cd ${ns_appbindir}/libexec ; dir=emacs/*/*/* ; $(MV_DIRS); \ rm -fr emacs ) ; \ ( cd ${ns_appbindir}/bin ; rm -f emacs emacs-23* ; \ ln -sf ../libexec/* .) ; \ else true ; fi ... as these lines of the log show: /Users/tetsushi/Gentoo26/bin/bash: line 5: cd: /Users/tetsushi/Gentoo26/var/tmp/portage/app-editors/emacs-23.1/work/emacs-23.1/nextstep/Emacs.app/Contents/MacOS/libexec: No such file or directory mv: cannot stat `emacs/*/*/*': No such file or directory So the "cd ${ns_appbindir}/libexec" already fails (note that there is no checking for errors). Therefore, it stays in the top-level dir where there is not subdirectory named "emacs". Now MV_DIRS is defined as follows: MV_DIRS = for i in $$dir; do rm -fr `basename "$$i"` ; mv "$$i" . ; done Hence, it will call basename on unexpanded "emacs/*/*/*", which will return "*" as target for "rm -fr" (and remember, we are still in the top-level build dir). Ugh. Do you want to report this bug upstream, or should I do it?
Please report from you. I'm not familiar with emacs development process.
Upstream bug report is here: <http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=5051>
Another minor point: --with-toolkit-scroll-bars is a valid configure option, so I think that the following line should be added to the "use cocoa" (or "use aqua") "if" block: myconf="${myconf} $(use_with toolkit-scroll-bars)"
emacs-cvs was moved to emacs-vcs (since upstream has switched from CVS to Bazaar). However, the cocoa port was released with version app-editors/emacs-23*, so changing summary to this.
if anyone still knows what's blocking this bug, please tell me
Created attachment 256918 [details] cocoa enabled 23.2 my current ebuild
Created attachment 256919 [details, diff] diff style patch against emacs-23.2.ebuild in prefix tree
Created attachment 256921 [details] used in attached 23.2 I realized the 'if test "${ns_appdir}" != ""' clauses aren't needed for us, since all files moved there are installed in $EPREFIX/usr/bin, etc.
I think the attached ebuild is at least better than the current code trying to enable disappeared carbon flags.
(In reply to comment #23) > Created an attachment (id=256919) [details] > > patch against emacs-23.2.ebuild in prefix tree Thank you. + if use cocoa; then + epatch "${FILESDIR}/${P}-ns_appdirs.patch" \ + || die "ns* patch failed"; + fi Is the conditional on "use cocoa" really necessary? As far as I can see, your patch doesn't affect any non-cocoa code. So the patch could be always applied?
(In reply to comment #26) > + if use cocoa; then > + epatch "${FILESDIR}/${P}-ns_appdirs.patch" \ > + || die "ns* patch failed"; > + fi > > Is the conditional on "use cocoa" really necessary? As far as I can see, your > patch doesn't affect any non-cocoa code. So the patch could be always applied? > Yes, it's possible to do so if you prefer.
(In reply to comment #27) > > So the patch could be always applied? > > Yes, it's possible to do so if you prefer. An unconditional patch is preferred, because we can eventually include it in the tarball of our patchset.
(In reply to comment #28) > An unconditional patch is preferred, because we can eventually include it in > the tarball of our patchset. Apart from this minor issue, both your ebuild and patch really look perfect to me. @Prefix team: Could this be committed to your overlay, with the small change that the ${P}-ns_appdirs.patch should be applied unconditionally? I'd really like to migrate app-editors/emacs back to the main tree, and it would be great if everything were ready at the time when 23.3 is released.
there is a small problem: it doesn't compile: make[2]: Leaving directory `/Library/Gentoo/var/tmp/portage/app-editors/emacs-23.2-r2/work/emacs-23.2/lisp' `/bin/pwd`/temacs --batch --load loadup bootstrap Loading loadup.el (source)... Wrong type argument: integerp, 3.0 make[1]: *** [bootstrap-emacs] Error 255 make[1]: Leaving directory `/Library/Gentoo/var/tmp/portage/app-editors/emacs-23.2-r2/work/emacs-23.2/src'
emacs-23.2-r2 haven't yet been imported to the prefix tree, so I don't know exactly what Fabian did, but I couldn't reproduce the compile error with ecopied & hand-patched -r2.
Sorry, I overlooked the 23.2-r2 in the prefix tree. But the conclusion is the same, I couldn't reproduce the error.
I committed my incorporation of your changes. Can you test them? If it compiles for you, it is Darwin 8 (OSX 10.4 Tiger) that is the problem. In any case, it feels it is unrelated to the Cocoa app building.
(In reply to comment #33) > I committed my incorporation of your changes. Can you test them? If it > compiles for you, it is Darwin 8 (OSX 10.4 Tiger) that is the problem. In any > case, it feels it is unrelated to the Cocoa app building. Apart from that Emacs 23.3 should ship a huge load of fixes, which maybe makes your problems go away.
(In reply to comment #33) > I committed my incorporation of your changes. Can you test them? If it > compiles for you, it is Darwin 8 (OSX 10.4 Tiger) that is the problem. In any > case, it feels it is unrelated to the Cocoa app building. > It works fine on Leopard. Thank you.
Ok, then I'll fix 32.2 for Darwin8 later, or wait for 32.3 first. In any case, ulm, 32.2-r1 should be the thing you're looking for now.
Created attachment 258763 [details, diff] alternative patch, intended for upstream I just notice that the upstream bug at http://debbugs.gnu.org/5051 is still open. Your patch is fine for Gentoo (where only the --disable-ns-self-contained case matters). However, we cannot send it upstream because some code in the Makefiles is removed, which I think is needed with the --enable-ns-self-contained configure option. Could you test if attached patch also works?
(In reply to comment #37) > Created an attachment (id=258763) [details] > alternative patch, intended for upstream > > I just notice that the upstream bug at http://debbugs.gnu.org/5051 is still > open. Your patch is fine for Gentoo (where only the --disable-ns-self-contained > case matters). However, we cannot send it upstream because some code in the > Makefiles is removed, which I think is needed with the > --enable-ns-self-contained configure option. > > Could you test if attached patch also works? > Unfortunately, it doesn't work. The aqua USE flag is for building Emacs.app, but your patch discards the building directory itself. We want Emacs.app, but we don't need Emacs.app/Contents/{MacOS/bin,Resources/share}/ because we have the same files in ${EPREFIX}/usr/{bin,share}/. (See comment#10 by Fabian.)
So that patch must remain Gentoo specific? That's unfortunate, because then a prefix-ready app-editors/emacs-vcs cannot be moved to the main tree (as we don't apply patches to live packages).
I can imagine upstream renders the patch useless. But I can live very well without any -vcs package or -9999 version, so that doesn't necessarily is a blocker for me.
I've merged the ebuild from the Prefix overlay with the existing EAPI 4 ebuild in the Emacs overlay: <http://overlays.gentoo.org/proj/emacs/changeset/1561> With the following changes: - Install as Emacs-${SLOT}.app instead of Emacs-${FULL_VERSION}.app (i.e. for 23.2 it will be Emacs-23.app instead of Emacs-23.2.1.app). That seems to fit better with existing systematics of file/slot naming. - Use doins -r for installation. - REQUIRED_USE="aqua? ( !X )" prevents simultaneous aqua and X flags, addressing the issue discussed in bug 315515. Could someone test this please? (Will require an EAPI 4 capable portage though).
(In reply to comment #41) > Could someone test this please? (Will require an EAPI 4 capable portage > though). Latest prefix portage is (rsync0 metadata generation is not yet)
(In reply to comment #41) > Could someone test this please? (Will require an EAPI 4 capable portage > though). Emacs-23.app/Contents/MacOS/Emacs should be executable, but it isn't: $ ls -l Applications/Gentoo/Emacs-23.app/Contents/MacOS/ total 9072 -rw-r--r-- 2 tetsushi staff 9288972 Jan 13 19:08 Emacs Does doins unset executable flag?
(In reply to comment #43) > Emacs-23.app/Contents/MacOS/Emacs should be executable, but it isn't: > $ ls -l Applications/Gentoo/Emacs-23.app/Contents/MacOS/ > total 9072 > -rw-r--r-- 2 tetsushi staff 9288972 Jan 13 19:08 Emacs > > Does doins unset executable flag? Yes, unfortunately. By default it sets all file modes to 0644 (which can be overridden by insopts, but that doesn't make sense with recursive doins). Is there anything else with special mode bits? Maybe you could attach the output of "find nextstep/Emacs.app -ls"?
I have the feeling that insinto is just not the right thing for special things like bundle-apps. It would more require an equivalent of exeinto, appinto or something. That is, however, way too specific to be acceptable, and a mv is much better and safer in this regard, IMO.
(In reply to comment #45) > [...] and a mv is much better and safer in this regard, IMO. I've changed the ebuild in the Emacs overlay (SVN r1564) to use mv again. Preceded by rm -rf, so that src_install can be restarted at least. IMHO, the real problem is that upstream's Makefile doesn't have any rules to install Emacs.app in DESTDIR.
(In reply to comment #41) > I've merged the ebuild from the Prefix overlay with the existing EAPI 4 > ebuild in the Emacs overlay: > <http://overlays.gentoo.org/proj/emacs/changeset/1561> Finally moved to Portage tree today, so I think this bug can be closed. Thanks again for the patches, and for testing.
migrated
