Hi, I noticed you removed the line configure.universal_args ${configure.args} the line should have read configure.universal_args {} which would still break 1.4 but work as expected when running the trunk. the reason the line can't simply be removed (doing so broke zlib +universal) is that the default universal variant is used, which includes CPPFLAGS, LDFLAGS and configure.args (--disable-dependency- tracking). Whereas the flags are fine and needed, the configure.args are not: <snip> ./configure <snip> --disable-dependency-tracking' unknown option: --disable-dependency-tracking so i overwrote them. one way or another that has to be done - only way around it would be to override the default universal variant and add the flags in there manually, which is a pain. i tried and it doesn't work: variant universal { set f "-arch i386 -arch ppc" configure.env-append \ CFLAGS="\${CFLAGS} -isysroot /Developer/SDKs/MacOSX10.4u.sdk $ {f}" \ LDFLAGS="\${LDFLAGS} ${f}" } make: *** Recursive variable `CFLAGS' references itself (eventually). Stop. Regards, Elias
This seems to be one of those "if you can't make it work in the current release (1.4) then you shouldn't do it situations" Until the current release has universal support then I would not commit universalized ports. On 1 Apr 2007, at 09:46, Elias Pipping wrote:
Hi,
I noticed you removed the line
configure.universal_args ${configure.args}
the line should have read
configure.universal_args {}
which would still break 1.4 but work as expected when running the trunk.
the reason the line can't simply be removed (doing so broke zlib +universal) is that the default universal variant is used, which includes CPPFLAGS, LDFLAGS and configure.args (--disable-dependency- tracking). Whereas the flags are fine and needed, the configure.args are not:
<snip> ./configure <snip> --disable-dependency-tracking' unknown option: --disable-dependency-tracking
so i overwrote them. one way or another that has to be done - only way around it would be to override the default universal variant and add the flags in there manually, which is a pain. i tried and it doesn't work:
variant universal { set f "-arch i386 -arch ppc" configure.env-append \ CFLAGS="\${CFLAGS} -isysroot /Developer/SDKs/MacOSX10.4u.sdk $ {f}" \ LDFLAGS="\${LDFLAGS} ${f}" }
make: *** Recursive variable `CFLAGS' references itself (eventually). Stop.
Regards,
Elias _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Randall Wood rhwood@mac.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy."
On Apr 1, 2007, at 09:12, Randall Wood wrote:
This seems to be one of those "if you can't make it work in the current release (1.4) then you shouldn't do it situations"
Until the current release has universal support then I would not commit universalized ports.
If we don't try to make ports universal now, we'll never know what universal support features we need from MacPorts. zlib +universal worked fine in MP 1.3.2 until the portfile was declared to be too ugly and got totally rewritten... I'll have more to say about that in a moment.
On Apr 1, 2007, at 7:43 PM, Ryan Schmidt wrote:
On Apr 1, 2007, at 09:12, Randall Wood wrote:
This seems to be one of those "if you can't make it work in the current release (1.4) then you shouldn't do it situations"
Until the current release has universal support then I would not commit universalized ports.
If we don't try to make ports universal now, we'll never know what universal support features we need from MacPorts.
zlib +universal worked fine in MP 1.3.2 until the portfile was declared to be too ugly and got totally rewritten... I'll have more to say about that in a moment.
the 'normal user' shouldn't be affected by universal variant related changes until that's an official feature. so it'd probably best to remove everything of that kind from the affected ports and instead make patches for testers running the trunk available. that'd affect: archivers/zlib/ devel/openssl/ devel/pcre/ editors/vim/ lang/scheme48/ net/curl/ textproc/libiconv/ www/neon/ i'll do that as soon asap and attach the patches to the corresponding article in the wiki. sorry for the inconvenience cause by universal variants (including a broken zlib). Regards, Elias
It may actually be best if you created a separate port tree that someone could include in their sources.conf file if they wanted to test it... On 1 Apr 2007, at 13:54, Elias Pipping wrote:
On Apr 1, 2007, at 7:43 PM, Ryan Schmidt wrote:
On Apr 1, 2007, at 09:12, Randall Wood wrote:
This seems to be one of those "if you can't make it work in the current release (1.4) then you shouldn't do it situations"
Until the current release has universal support then I would not commit universalized ports.
If we don't try to make ports universal now, we'll never know what universal support features we need from MacPorts.
zlib +universal worked fine in MP 1.3.2 until the portfile was declared to be too ugly and got totally rewritten... I'll have more to say about that in a moment.
the 'normal user' shouldn't be affected by universal variant related changes until that's an official feature. so it'd probably best to remove everything of that kind from the affected ports and instead make patches for testers running the trunk available.
that'd affect:
archivers/zlib/ devel/openssl/ devel/pcre/ editors/vim/ lang/scheme48/ net/curl/ textproc/libiconv/ www/neon/
i'll do that as soon asap and attach the patches to the corresponding article in the wiki. sorry for the inconvenience cause by universal variants (including a broken zlib).
Regards,
Elias
Randall Wood rhwood@mac.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy."
On Apr 1, 2007, at 10:43 AM, Ryan Schmidt wrote:
zlib +universal worked fine in MP 1.3.2 until the portfile was declared to be too ugly and got totally rewritten... I'll have more to say about that in a moment.
No, it did not. The port broke because the 'command' private API was used. Period. I rewrote the port to remove the private APIs, which disabled the obviously experimental universal support. I didn't test pipping's new universal support because I didn't write (or commit) the universal support. -landonf
On Apr 1, 2007, at 11:34 AM, Landon Fuller wrote:
On Apr 1, 2007, at 10:43 AM, Ryan Schmidt wrote:
zlib +universal worked fine in MP 1.3.2 until the portfile was declared to be too ugly and got totally rewritten... I'll have more to say about that in a moment.
No, it did not.
The port broke because the 'command' private API was used. Period. I rewrote the port to remove the private APIs, which disabled the obviously experimental universal support.
And in case it's not clear, the port functioned correctly afterwards.
I didn't test pipping's new universal support because I didn't write (or commit) the universal support.
participants (4)
-
Elias Pipping
-
Landon Fuller
-
Randall Wood
-
Ryan Schmidt