port should not complain about +universal, CFLAGS/LDFLAGS, configure.universal_cflags-append/configure.universal_ldflags-append
When installing gettext +universal, port warns me that it might not work because the port already overrides CFLAGS or LDFLAGS: $ sudo port install gettext +universal Warning: This port already overrides CFLAGS or LDFLAGS. The universal variant may break it. ---> Extracting gettext ---> Applying patches to gettext ---> Configuring gettext ---> Building gettext with target all ---> Staging gettext into destroot ---> Installing gettext 0.16.1_0+universal ---> Activating gettext 0.16.1_0+universal $ However, this is not a problem here because the gettext port deals with the situation: if {[llength [info commands configure.universal_ldflags-append]] > 0} { configure.universal_ldflags-append -L$prefix/lib configure.universal_cflags-append -I$prefix/include -no-cpp-precomp } else { variant universal { return -code error "You need to be running MacPorts 1.4.0 or higher to \ use this variant (universal)." } } port should not print that warning if configure.universal_cflags- append or .universal_ldflags-append are used.
Let's wait for official support of +universal with that... eventually the whole if clause will be gone anyway. I mean really, there's worse problems than obsolete warnings, 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) see also http://page.mi.fu-berlin.de/~pipping/macports/universal for a list of such problems. Regards Elias On Mar 18, 2007, at 7:00 AM, Ryan Schmidt wrote:
When installing gettext +universal, port warns me that it might not work because the port already overrides CFLAGS or LDFLAGS:
$ sudo port install gettext +universal Warning: This port already overrides CFLAGS or LDFLAGS. The universal variant may break it. ---> Extracting gettext ---> Applying patches to gettext ---> Configuring gettext ---> Building gettext with target all ---> Staging gettext into destroot ---> Installing gettext 0.16.1_0+universal ---> Activating gettext 0.16.1_0+universal $
However, this is not a problem here because the gettext port deals with the situation:
if {[llength [info commands configure.universal_ldflags-append]] > 0} { configure.universal_ldflags-append -L$prefix/lib configure.universal_cflags-append -I$prefix/include -no-cpp-precomp } else { variant universal { return -code error "You need to be running MacPorts 1.4.0 or higher to \ use this variant (universal)." } }
port should not print that warning if configure.universal_cflags- append or .universal_ldflags-append are used.
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Can you put that list in Trac? On 18 Mar 2007, at 06:52, Elias Pipping wrote:
Let's wait for official support of +universal with that...
eventually the whole if clause will be gone anyway.
I mean really, there's worse problems than obsolete warnings, 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)
see also http://page.mi.fu-berlin.de/~pipping/macports/universal for a list of such problems.
Regards
Elias
On Mar 18, 2007, at 7:00 AM, Ryan Schmidt wrote:
When installing gettext +universal, port warns me that it might not work because the port already overrides CFLAGS or LDFLAGS:
$ sudo port install gettext +universal Warning: This port already overrides CFLAGS or LDFLAGS. The universal variant may break it. ---> Extracting gettext ---> Applying patches to gettext ---> Configuring gettext ---> Building gettext with target all ---> Staging gettext into destroot ---> Installing gettext 0.16.1_0+universal ---> Activating gettext 0.16.1_0+universal $
However, this is not a problem here because the gettext port deals with the situation:
if {[llength [info commands configure.universal_ldflags-append]] > 0} { configure.universal_ldflags-append -L$prefix/lib configure.universal_cflags-append -I$prefix/include -no-cpp-precomp } else { variant universal { return -code error "You need to be running MacPorts 1.4.0 or higher to \ use this variant (universal)." } }
port should not print that warning if configure.universal_cflags- append or .universal_ldflags-append are used.
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
_______________________________________________ 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."
Sure, where would you want me to put it? On Mar 18, 2007, at 12:14 PM, Randall Wood wrote:
Can you put that list in Trac?
On 18 Mar 2007, at 06:52, Elias Pipping wrote:
Let's wait for official support of +universal with that...
eventually the whole if clause will be gone anyway.
I mean really, there's worse problems than obsolete warnings, 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)
see also http://page.mi.fu-berlin.de/~pipping/macports/universal for a list of such problems.
Regards
Elias
On Mar 18, 2007, at 7:00 AM, Ryan Schmidt wrote:
When installing gettext +universal, port warns me that it might not work because the port already overrides CFLAGS or LDFLAGS:
$ sudo port install gettext +universal Warning: This port already overrides CFLAGS or LDFLAGS. The universal variant may break it. ---> Extracting gettext ---> Applying patches to gettext ---> Configuring gettext ---> Building gettext with target all ---> Staging gettext into destroot ---> Installing gettext 0.16.1_0+universal ---> Activating gettext 0.16.1_0+universal $
However, this is not a problem here because the gettext port deals with the situation:
if {[llength [info commands configure.universal_ldflags-append]]
0} { configure.universal_ldflags-append -L$prefix/lib configure.universal_cflags-append -I$prefix/include -no-cpp-precomp } else { variant universal { return -code error "You need to be running MacPorts 1.4.0 or higher to \ use this variant (universal)." } }
port should not print that warning if configure.universal_cflags- append or .universal_ldflags-append are used.
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
_______________________________________________ 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."
Why don't we create it at https://svn.macosforge.org/projects/ macports/wiki/Universal On 18 Mar 2007, at 07:26, Elias Pipping wrote:
Sure, where would you want me to put it?
On Mar 18, 2007, at 12:14 PM, Randall Wood wrote:
Can you put that list in Trac?
On 18 Mar 2007, at 06:52, Elias Pipping wrote:
Let's wait for official support of +universal with that...
eventually the whole if clause will be gone anyway.
I mean really, there's worse problems than obsolete warnings, 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)
see also http://page.mi.fu-berlin.de/~pipping/macports/universal for a list of such problems.
Regards
Elias
On Mar 18, 2007, at 7:00 AM, Ryan Schmidt wrote:
When installing gettext +universal, port warns me that it might not work because the port already overrides CFLAGS or LDFLAGS:
$ sudo port install gettext +universal Warning: This port already overrides CFLAGS or LDFLAGS. The universal variant may break it. ---> Extracting gettext ---> Applying patches to gettext ---> Configuring gettext ---> Building gettext with target all ---> Staging gettext into destroot ---> Installing gettext 0.16.1_0+universal ---> Activating gettext 0.16.1_0+universal $
However, this is not a problem here because the gettext port deals with the situation:
if {[llength [info commands configure.universal_ldflags-append]]
0} { configure.universal_ldflags-append -L$prefix/lib configure.universal_cflags-append -I$prefix/include -no-cpp- precomp } else { variant universal { return -code error "You need to be running MacPorts 1.4.0 or higher to \ use this variant (universal)." } }
port should not print that warning if configure.universal_cflags- append or .universal_ldflags-append are used.
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
_______________________________________________ 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."
Randall Wood rhwood@mac.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy."
The list can now be found here: https://svn.macosforge.org/projects/macports/wiki/Universal Regards, Elias On Mar 18, 2007, at 12:46 PM, Randall Wood wrote:
Why don't we create it at https://svn.macosforge.org/projects/ macports/wiki/Universal
On 18 Mar 2007, at 07:26, Elias Pipping wrote:
Sure, where would you want me to put it?
On Mar 18, 2007, at 12:14 PM, Randall Wood wrote:
Can you put that list in Trac?
On 18 Mar 2007, at 06:52, Elias Pipping wrote:
Let's wait for official support of +universal with that...
eventually the whole if clause will be gone anyway.
I mean really, there's worse problems than obsolete warnings, 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)
see also http://page.mi.fu-berlin.de/~pipping/macports/universal for a list of such problems.
Regards
Elias
On Mar 18, 2007, at 7:00 AM, Ryan Schmidt wrote:
When installing gettext +universal, port warns me that it might not work because the port already overrides CFLAGS or LDFLAGS:
$ sudo port install gettext +universal Warning: This port already overrides CFLAGS or LDFLAGS. The universal variant may break it. ---> Extracting gettext ---> Applying patches to gettext ---> Configuring gettext ---> Building gettext with target all ---> Staging gettext into destroot ---> Installing gettext 0.16.1_0+universal ---> Activating gettext 0.16.1_0+universal $
However, this is not a problem here because the gettext port deals with the situation:
if {[llength [info commands configure.universal_ldflags- append]] > 0} { configure.universal_ldflags-append -L$prefix/lib configure.universal_cflags-append -I$prefix/include -no-cpp- precomp } else { variant universal { return -code error "You need to be running MacPorts 1.4.0 or higher to \ use this variant (universal)." } }
port should not print that warning if configure.universal_cflags-append or .universal_ldflags-append are used.
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
_______________________________________________ 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."
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 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.
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
On Mar 23, 2007, at 7:21 PM, 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.
I concur. And I am very glad you guys are testing universal builds. I still develop on a G4 machine, though...
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?
Elias just fixed that.
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.
This was fixed by the recent upgrade of the +universal logic, which is based on the new configure environment support code. Paul
participants (4)
-
Elias Pipping
-
Paul Guyot
-
Randall Wood
-
Ryan Schmidt