port should not complain about +universal, CFLAGS/LDFLAGS,
configure.universal_cflags-append/configure.universal_ldflags-append
Ryan Schmidt
ryandesign at macports.org
Fri Mar 23 03:21:33 PDT 2007
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?
> 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.
> 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.
> 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.
More information about the macports-dev
mailing list