On Mar 23, 2007, at 11:21 AM, Ryan Schmidt wrote:
On Mar 18, 2007, at 05:52, Elias Pipping wrote:
Let's wait for official support of +universal with that...
Well, how will we get official support of +universal unless we push
for it? Now that I have an Intel Mac, it no longer takes forever
for me to compile things, so I'm trying to build as many things
universal as I can. And I will continue to bring to the list's
attention all problems I encounter in this endeavor. And we should
all try our best to fix the problems.
When will we get +universal anyway? Right now, I'm running MacPorts
compiled from trunk, a.k.a. 1.500, because the 1.4rc2 release
doesn't appear to contain the default +universal variant. The
messages that have been inserted into some portfiles suggest that
the default +universal variant should have been in MacPorts 1.400.
So what's up?
that was done before the version of the trunk was bumped to 1.5. -
it's malinformation now
eventually the whole if clause will be gone anyway.
I understand that the if clause in the portfiles testing for the
universal functionality will go away, once that functionality is
generally available. That does not fix the problem that the port
system will still print a warning that the port might fail to build
universally, when in fact it will not. I stand by my original
statement that the port system should not print the warning about
the CFLAGS or LDFLAGS if the portfile uses the
configure.universal_cflags-append or configure.universal_ldflags-
append options.
that was unrelated to the issue you described, indeed.
I mean really, there's worse problems than obsolete warnings
I think inaccurate warnings are almost worse than no warnings. If I
try to install something universal, and it says "warning! this may
not work!" then I will stop the build and examine the portfile to
see what I think. Then I find the configure.universal_cflags-append
bit or whatever which means it most likely will work because
someone has gone out of their way to add that specifically for
universal support. So then I get annoyed that I was made to check
the portfile source.
Maybe this is all a moot point if the "universal_ok" flag is
implemented as I described in the other thread. Then portfiles
known to build universally can include "universal_ok yes", and the
port system can then check just for that variable and not bother
checking for CFLAGS, LDFLAGS or anything else.
sounds good - and a port that doesn't have that flag shouldn't
display 'universal' as a variant.
especially with gettext. e.g. gettext +universal is somehow
incomplete: all the libasprintf-related files are missing
completely. diff the results of port contents with and without
+universal and see for yourself (ideas, patches appreciated)
Hmm. I wasn't aware of that. But I have no idea what libasprintf is
or why I would want it, and I don't know what to do about its
absence either.
I've fixed it in a recent commit[1]. the problems was simply that
gettext is written in C++, hence g++ needs the same flags as gcc (the
isysroot and the arch flags). gettext +universal is now stable[2].
[1] http://trac.macports.org/projects/macports/changeset/23028
[2] http://trac.macports.org/projects/macports/wiki/
Universal#gettext0.16.1_0
Regards,
Elias
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
