Hi, I took the time to make the ebuild for plan9port-20140306 prefix safe. The existing ebuild hard codes the install path as /usr/lib/plan9, I added the correct prefix where applicable. The changes have been tested on amd64 prefix (RHEL) and on a amd64 gentoo machine - everything works same as before. It may be a good idea to keyword the ebuild as well. Below is my patch. Reproducible: Always
Created attachment 418290 [details, diff] patch to make ebuild prefix safe
Created attachment 418314 [details, diff] plan9port-prefix.patch Thanks Jeremi, I have revised your patch. Andy, Anthony, is it okay to commit this Prefix support?
If EPLAN9 is basically used everywhere (except with ED), why don't we redefine PLAN9 as EPLAN9 and use D iso ED (basically make no change). It will reduce the diff. The sedding looks awkward, but likely a necessity.
(In reply to Fabian Groffen from comment #3) > If EPLAN9 is basically used everywhere (except with ED), why don't we > redefine PLAN9 as EPLAN9 and use D iso ED (basically make no change). It > will reduce the diff. > > The sedding looks awkward, but likely a necessity. I committed this as plan9port-20140306-r1.ebuild before I read you comment Fabian. PLAN9 is being used in addition to EPLAN9 so I'm not sure there's much more to clean up that can be done. If you want, feel free to touch that packages. I'm closing this, but reopen if there's a problem or more discussion.
I finally had the chance to test the new ebuild on an OSX prefix and found the following issues: 1. the 'as' present in binutils-apple does not support flags with two dashes --, only single dashes. This causes a problem with the gentoo patch plan9port-noexecstack.patch which forces passing --noexecstack to as. I found that dropping one of the dashes, leaving only -noexecstack, work fine on OSX and with the gnu assembler on linux (hope the flag is not getting ignored). This requires changing both plan9port-noexecstack.patch and plan9port-cflags.patch. 2. autodetection of window system. The script src/cmd/devdraw/mkwsysrules.sh is responsible for autodetecting whether to use X11, Cocoa or Carbon (for OSX <=10.5). The corresponding WSYSTYPE settings in LOCAL.config are x11, osx-cocoa, and osx. I think it's best to not rely on this and to explicitly set one with a USE flag. Below is my take on this: --- a/dev-util/plan9port/plan9port-20140306-r1.ebuild +++ b/dev-util/plan9port/plan9port-20140306-r1.ebuild @@ -13,7 +13,8 @@ SRC_URI="https://${PN}.googlecode.com/files/${P}.tgz" LICENSE="9base BSD-4 MIT LGPL-2.1 BigelowHolmes" SLOT="0" KEYWORDS="~amd64 ~x86" -IUSE="X" +IUSE="X aqua" +REQUIRED_USE="?? ( X aqua )" DEPEND="X? ( x11-apps/xauth )" RDEPEND="${DEPEND}" @@ -47,6 +48,9 @@ src_prepare() { src_configure() { if use X; then echo "X11=${EPREFIX}/usr" >> LOCAL.config + echo "WSYSTYPE=x11" >> LOCAL.config + elif use aqua; then + local wstype=$(sw_vers -productVersion | awk '{ if ($1 > 10.5) print "osx-cocoa"; else print "osx" }') + echo "WSYSTYPE=${wstype}" >> LOCAL.config else echo "WSYSTYPE=nowsys" >> LOCAL.config fi I don't know enough about OSX and prefix on OSX to know whether this is the best way to do this. 3. the bin/9c script which is used for building uses the CC9 env variable to detect whether to use clang or gcc. By default gcc will be used. For OSX prefix this means the system gcc because there isn't one in the prefix. A well placed `export CC9=$(tc-getCC)` should take care of that one, but I don't know if this is worth the hassle.
(In reply to Jeremi Piotrowski from comment #5) > I finally had the chance to test the new ebuild on an OSX prefix and found > the following issues: I can work with this but try to attach patches rather than cut and paste since the latter gives rise to whitespace damage. Only if you are "suggesting" a fix then its okay to inline it, but say you're just suggesting. It save me more trouble than you'd imagine! > > 1. the 'as' present in binutils-apple does not support flags with two dashes > --, only single dashes. > > This causes a problem with the gentoo patch plan9port-noexecstack.patch > which forces passing --noexecstack to as. I found that dropping one of the > dashes, leaving only -noexecstack, work fine on OSX and with the gnu > assembler on linux (hope the flag is not getting ignored). This requires > changing both plan9port-noexecstack.patch and plan9port-cflags.patch. > > 2. autodetection of window system. > > The script src/cmd/devdraw/mkwsysrules.sh is responsible for autodetecting > whether to use X11, Cocoa or Carbon (for OSX <=10.5). The corresponding > WSYSTYPE settings in LOCAL.config are x11, osx-cocoa, and osx. I think it's > best to not rely on this and to explicitly set one with a USE flag. Below is > my take on this: > > --- a/dev-util/plan9port/plan9port-20140306-r1.ebuild > +++ b/dev-util/plan9port/plan9port-20140306-r1.ebuild > @@ -13,7 +13,8 @@ SRC_URI="https://${PN}.googlecode.com/files/${P}.tgz" > LICENSE="9base BSD-4 MIT LGPL-2.1 BigelowHolmes" > SLOT="0" > KEYWORDS="~amd64 ~x86" > -IUSE="X" > +IUSE="X aqua" > +REQUIRED_USE="?? ( X aqua )" > > DEPEND="X? ( x11-apps/xauth )" > RDEPEND="${DEPEND}" > @@ -47,6 +48,9 @@ src_prepare() { > src_configure() { > if use X; then > echo "X11=${EPREFIX}/usr" >> LOCAL.config > + echo "WSYSTYPE=x11" >> LOCAL.config > + elif use aqua; then > + local wstype=$(sw_vers -productVersion | awk '{ if ($1 > 10.5) print > "osx-cocoa"; else print "osx" }') > + echo "WSYSTYPE=${wstype}" >> LOCAL.config > else > echo "WSYSTYPE=nowsys" >> LOCAL.config > fi > > I don't know enough about OSX and prefix on OSX to know whether this is the > best way to do this. This looks sane if it works. So I'm not familiar enough with macs to know what sw_vers -productVersion. If you say it works, I'll just believe you :) Do any of the prefix people know? > > 3. the bin/9c script which is used for building uses the CC9 env variable to > detect whether to use clang or gcc. > > By default gcc will be used. For OSX prefix this means the system gcc > because there isn't one in the prefix. A well placed `export > CC9=$(tc-getCC)` should take care of that one, but I don't know if this is > worth the hassle. Again, not sure. prefix folks? any hints here.
(In reply to Fabian Groffen from comment #3) > If EPLAN9 is basically used everywhere (except with ED), why don't we > redefine PLAN9 as EPLAN9 and use D iso ED (basically make no change). It > will reduce the diff. Thanks Fabian. But not really. In the ebuild, there are things like dodir "${PLAN9}" docompress -x $PLAN9/man which need to use a directory without EPREFIX. > The sedding looks awkward, but likely a necessity. Yeah, it is necessary. It irony that plan9 aiming for a clean system has such a dirty build system. Thanks Anthony! Sorry I am not familiar with Mac either.
(In reply to Anthony Basile from comment #6) > I can work with this but try to attach patches rather than cut and paste > since the latter gives rise to whitespace damage. Only if you are > "suggesting" a fix then its okay to inline it, but say you're just > suggesting. It save me more trouble than you'd imagine! > Sorry, I should've mentioned that I kind of improvised this fix based on what is already there in the plan9port build system, and some of the patch was written right here in the text box. If there's a better facility for getting version numbers within ebuilds in prefix it would be preferable.
Please don't use sw_vers, just use a CHOST check instead (or MACOSX_DEPLOYMENT_TARGET if you want). Those are properly set values from the profile (which indicate what the rest of the software is installed as).
I can't do much more with this because I'm not familiar with the target. I'll be happy to apply more patches.
Created attachment 420966 [details, diff] plan9port-20140306-r2.ebuild.patch Here is the patch. I added USE flags, the AFLAGS fix on OSX and a FreeBSD10 fix to 9l (could/should be extended to future version). I also tried not to leave anything autodetected so src_configure has grown. Finally, I force the usage of the gentoo compiler by exporting CC9. I test the build on gentoo, and the following prefixes: osx-10.9, freebsd9, freebsd10 and centos. My test case is acme running and it does everywhere. The only other problem I noticed is 9term erroring out with "9term: no ptys" on freebsd10. I found that that's due to them removing legacy bsd pty support. If the Linux implementation is selected in src/cmd/9term/mkfile then 9term appears to work but I'm not sure about that fix yet.
Created attachment 420968 [details, diff] plan9port-freebsd-10.patch This is the new FreeBDS10 patch to 9l that I apply in src_prepare.
(In reply to Jeremi Piotrowski from comment #12) > Created attachment 420968 [details, diff] [details, diff] > plan9port-freebsd-10.patch > > This is the new FreeBDS10 patch to 9l that I apply in src_prepare. okay this is added. the only issue i see is that the freebsd patch is applied conditionally but its minor in this case. i think we're done here. please test and reopen if there's anything more to do