Elias,
Thanks, that does work now.
Regards,
Blair
Elias Pipping wrote:
r22321 should fix the problem.
please let me know if it does/doesn't.
Regards,
Elias Pipping
On Feb 26, 2007, at 8:34 AM, Blair Zajac wrote:
That's a pretty important port, it's at the very bottom of any
dependency trees, so I think we should.
This kinda raises the point for me, that maybe we should consider
having a build farm of 10.3 and 10.4 PPC and i386 that check
submissions, ala a smoke test, and after each Subversion commit, the
new Ports are built on all platforms. If it breaks, the author of the
commit gets an email.
I imagine that not everybody has 10.3 around, but I do consider it an
important OS X release, as many corporations still haven't upgraded
everything to 10.4 yet.
Thanks,
Blair
Elias Pipping wrote:
Well, i could comment it out for now - until 1.4.0 is out. Should I?
that option is indeed needed for +universal to work, though.
Regards,
Elias Pipping
On Feb 26, 2007, at 8:23 AM, Blair Zajac wrote:
And do we have to wait for MacPorts 1.4.0 before using these new
commands.
For example, right now libiconv is broken. If you try to build
something that depends upon it:
$ port -v build libxml2
Error: Unable to execute port: invalid command name
"configure.universal_ldflags-append"
I'm presuming this is from this line in
dports/textproc/libiconv/Portfile:
+configure.universal_ldflags-append \
+ -isysroot /Developer/SDKs/MacOSX10.4u.sdk
Regards,
Blair
Blair Zajac wrote:
Hi Paul,
I looked through the diff for r22313 and didn't see anything that
checks for OS X versions 10.3 or older, so will this break on older
OSes? If it will break things, can you update the code to add this
check?
I support a binary install of MacPorts on a portable firewire drive
that runs Apache, MySQL etc and we need to support 10.3 clients.
Regards,
Blair
Elias Pipping wrote:
That is a lovely addition and I embrace it wholeheartedly.
Now more than ever it brings up the need for a database that
contains information on which port builds on what platform and if
its variant +universal works, though.
So a port would have these entries e.g.:
db44 ppc i386 universal
Panther ? ? ?
Tiger X ? X
Leopard ? ? ?
or something like that. maybe i'm the only one to see it that way
but i find it problematic to just assume away every port builds on
every platform and is perfectly stable. also, is it really a good
idea to keep adding -devel ports instead of allowing a port to be
available as multiple "branches"? like bash 3.1.17 and 3.2.9 as a
3.1 and a 3.2 branch (yes, i'm thinking of gentoo - stable,
testing, etc)?
Regards,
Elias Pipping
On Feb 26, 2007, at 5:45 AM, Paul Guyot wrote:
Dear all,
I've just implemented and committed a default +universal variant
for configure-based ports. There's been some heat about
+universal recently and I did not want every port to define the
same code over and over.
This variant is more or less equivalent to:
variant universal {
configure.args-append "--disable-dependency-tracking"
configure.env-append CFLAGS="-isysroot
/Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"
LDFLAGS="-arch i386 -arch ppc"
}
However, there is some additional magic:
* selecting the variant will fail if the port doesn't invoke
configure (because user may think they can build the port
universal while it would be effectless)
* selecting the variant will print a warning message if the port
already overrides LDFLAGS or CFLAGS in the environment for the
configure command
* you can add -O -g if the port requires it with just:
configure.universal_cflags-append -O -g
* you can simply redefine the variant to override the default
code and provide port-specific handler for the universal variant.
etc.
The variant is documented in portfile(7). I tested it with
several ports and it seems to just work®™.
I'm considering some future enhancements, but let's see what it
gives if we start building ports with +universal. Of course, the
build will probably fail if dependencies were not built universal.
Enjoy!
Paul
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
