Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 268793 - app-editors/emacs-23*: lift ban of 'aqua'
Summary: app-editors/emacs-23*: lift ban of 'aqua'
Status: RESOLVED FIXED
Alias: None
Product: Gentoo/Alt
Classification: Unclassified
Component: Prefix Support (show other bugs)
Hardware: x86 OS X
: High enhancement (vote)
Assignee: Gentoo Prefix
URL: http://debbugs.gnu.org/cgi/bugreport....
Whiteboard:
Keywords:
Depends on:
Blocks: 315515
  Show dependency tree
 
Reported: 2009-05-06 08:06 UTC by MATSUI Tetsushi
Modified: 2011-01-30 10:15 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
cocoa enabled 23.0.93 ebuild (emacs-cvs-23.0.93.ebuild,9.76 KB, text/plain)
2009-05-06 08:12 UTC, MATSUI Tetsushi
Details
diff against ecopied 23.0.96 (emacs-cvs-23.0.96.diff,3.18 KB, patch)
2009-07-17 04:39 UTC, MATSUI Tetsushi
Details | Diff
faillog (faillog,226.12 KB, text/plain)
2009-11-26 15:56 UTC, MATSUI Tetsushi
Details
cocoa enabled 23.2 (emacs-23.2.ebuild,10.74 KB, text/plain)
2010-12-11 19:03 UTC, MATSUI Tetsushi
Details
diff style (emacs-23.2.diff,2.86 KB, patch)
2010-12-11 19:05 UTC, MATSUI Tetsushi
Details | Diff
used in attached 23.2 (emacs-23.2-ns_appdirs.patch,1.92 KB, text/plain)
2010-12-11 19:10 UTC, MATSUI Tetsushi
Details
alternative patch, intended for upstream (emacs-23.2-ns-appdirs.patch,1.75 KB, patch)
2011-01-03 18:27 UTC, Ulrich Müller
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description MATSUI Tetsushi 2009-05-06 08:06:33 UTC
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.
Comment 1 MATSUI Tetsushi 2009-05-06 08:12:59 UTC
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.
Comment 2 Jeremy Olexa (darkside) (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2009-06-05 21:20:56 UTC
(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.
Comment 3 MATSUI Tetsushi 2009-06-07 17:38:33 UTC
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.
Comment 4 MATSUI Tetsushi 2009-07-17 04:39:07 UTC
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.
Comment 5 Christian Faulhammer (RETIRED) gentoo-dev 2009-11-24 20:30:34 UTC
Basically this looks sane, although I cannot evaluate all parts of the "hackish" lines.
Comment 6 Christian Faulhammer (RETIRED) gentoo-dev 2009-11-25 20:10:03 UTC
After discussion with my fellow Emacs team mate ulm about the patch we think that the patch needs some love.  Details will follow soon.
Comment 7 Ulrich Müller gentoo-dev 2009-11-25 20:28:15 UTC
(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.
Comment 8 MATSUI Tetsushi 2009-11-26 03:08:14 UTC
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.
Comment 9 Ulrich Müller gentoo-dev 2009-11-26 08:36:01 UTC
(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?
Comment 10 Fabian Groffen gentoo-dev 2009-11-26 09:14:49 UTC
(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.
Comment 11 Ulrich Müller gentoo-dev 2009-11-26 09:26:50 UTC
(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?
Comment 12 Fabian Groffen gentoo-dev 2009-11-26 09:32:26 UTC
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.
Comment 13 MATSUI Tetsushi 2009-11-26 12:25:27 UTC
(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.
Comment 14 Ulrich Müller gentoo-dev 2009-11-26 13:00:53 UTC
(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.
Comment 15 MATSUI Tetsushi 2009-11-26 15:56:31 UTC
Created attachment 211254 [details]
faillog

log w/o make install-arch-dep, failed as comment 13.
Comment 16 Ulrich Müller gentoo-dev 2009-11-26 16:16:41 UTC
(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?
Comment 17 MATSUI Tetsushi 2009-11-26 16:38:24 UTC
Please report from you.  I'm not familiar with emacs development process.
Comment 18 Ulrich Müller gentoo-dev 2009-11-26 19:51:23 UTC
Upstream bug report is here:
<http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=5051>
Comment 19 Ulrich Müller gentoo-dev 2009-11-26 20:45:17 UTC
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)"

Comment 20 Ulrich Müller gentoo-dev 2009-12-27 20:12:03 UTC
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.
Comment 21 Fabian Groffen gentoo-dev 2010-07-09 20:14:36 UTC
if anyone still knows what's blocking this bug, please tell me
Comment 22 MATSUI Tetsushi 2010-12-11 19:03:01 UTC
Created attachment 256918 [details]
cocoa enabled 23.2

my current ebuild
Comment 23 MATSUI Tetsushi 2010-12-11 19:05:20 UTC
Created attachment 256919 [details, diff]
diff style

patch against emacs-23.2.ebuild in prefix tree
Comment 24 MATSUI Tetsushi 2010-12-11 19:10:06 UTC
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.
Comment 25 MATSUI Tetsushi 2010-12-11 19:17:06 UTC
I think the attached ebuild is at least better than the current code trying to enable disappeared carbon flags.
Comment 26 Ulrich Müller gentoo-dev 2010-12-11 20:13:56 UTC
(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?
Comment 27 MATSUI Tetsushi 2010-12-12 02:59:48 UTC
(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.
Comment 28 Ulrich Müller gentoo-dev 2010-12-12 13:44:25 UTC
(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.
Comment 29 Ulrich Müller gentoo-dev 2011-01-01 23:12:14 UTC
(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.
Comment 30 Fabian Groffen gentoo-dev 2011-01-02 17:30:43 UTC
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'
Comment 31 MATSUI Tetsushi 2011-01-03 01:35:06 UTC
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.
Comment 32 MATSUI Tetsushi 2011-01-03 02:25:43 UTC
Sorry, I overlooked the 23.2-r2 in the prefix tree.
But the conclusion is the same, I couldn't reproduce the error.

Comment 33 Fabian Groffen gentoo-dev 2011-01-03 11:46:03 UTC
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.
Comment 34 Christian Faulhammer (RETIRED) gentoo-dev 2011-01-03 14:31:28 UTC
(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.
Comment 35 MATSUI Tetsushi 2011-01-03 15:24:15 UTC
(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.
Comment 36 Fabian Groffen gentoo-dev 2011-01-03 15:45:49 UTC
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.
Comment 37 Ulrich Müller gentoo-dev 2011-01-03 18:27:09 UTC
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?
Comment 38 MATSUI Tetsushi 2011-01-04 16:16:12 UTC
(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.)
Comment 39 Ulrich Müller gentoo-dev 2011-01-04 17:28:17 UTC
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).
Comment 40 Fabian Groffen gentoo-dev 2011-01-04 17:31:23 UTC
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.
Comment 41 Ulrich Müller gentoo-dev 2011-01-11 23:28:11 UTC
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).
Comment 42 Fabian Groffen gentoo-dev 2011-01-12 09:13:12 UTC
(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)

Comment 43 MATSUI Tetsushi 2011-01-13 10:27:08 UTC
(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?
Comment 44 Ulrich Müller gentoo-dev 2011-01-13 11:35:24 UTC
(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"?
Comment 45 Fabian Groffen gentoo-dev 2011-01-13 11:40:06 UTC
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.
Comment 46 Ulrich Müller gentoo-dev 2011-01-13 13:33:14 UTC
(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.
Comment 47 Ulrich Müller gentoo-dev 2011-01-30 09:20:34 UTC
(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.
Comment 48 Fabian Groffen gentoo-dev 2011-01-30 10:15:19 UTC
migrated