I'm merging these two threads to create a new one, because * they (now) deal with the same topic * their names are too long and unrelated to the current topic so please * reply to this email instead * leave off the (was: ...) part Regards, Elias Begin forwarded message:
From: Elias Pipping <pipping@macports.org> Date: March 23, 2007 3:24:25 PM GMT+01:00 To: Ryan Schmidt <ryandesign@macports.org> Cc: Macports dev <macports-dev@lists.macosforge.org> Subject: Re: port should not complain about +universal, CFLAGS/ LDFLAGS, configure.universal_cflags-append/ configure.universal_ldflags-append
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 macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev Begin forwarded message:
From: Elias Pipping <pipping@macports.org> Date: March 23, 2007 3:33:38 PM GMT+01:00 To: Ryan Schmidt <ryandesign@macports.org> Cc: Macports Dev <macports-dev@lists.macosforge.org> Subject: Re: Newbie ncursesw problem - can't install apache2
On Mar 23, 2007, at 11:10 AM, Ryan Schmidt wrote:
On Mar 20, 2007, at 10:57, Elias Pipping wrote:
This is a serious problem btw. That "oh there's a universal variant, it'll surely work" thought, which is perfectly natural but doesn't work in this case. That's why
http://trac.macosforge.org/projects/macports/wiki/Universal
needs to be extended and made aware of. (alternatively, a port could be required to hold some keyword in order to allow for building with +universal. like 'build_universal yes' or something.
I think your wiki list is perhaps helpful right now, but not a viable long-term solution. I would want a solution that's completely contained within the MacPorts software.
It wasn't meant to be a standalone solution. A start rather. I'd like an infrastructure like the guys over at gentoo have it.[1] (without the wait for something to become stable, though, at least at first)
I would prefer a variable named something like "universal_works" or "universal_ok" which could be set to "yes" or "no". The default would be neither, more of an "I don't know" or "maybe" state. Ports where the maintainer has tried the +universal variant and believes it to work should have "universal_ok yes" added. Ports that have been tested and found not to work universally should be marked with "universal_ok no" (that's assuming they cannot be easily fixed to work universally). Anyone who tries to build a port that has neither marking would get a warning that the universal build is untested, and that they should let us know if they find that it works or doesn't work.
That's good for now, but it's only a short term solution as well, because it only says something about the universal variant whereas we need information about what works for every package on every supported platform with every variant (the variants will be ugly).
[1] http://packages.gentoo.org/search/?sstring=bash
Regards,
Elias _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev