Always add -L${prefix}/lib, -I${prefix}/include?
Many ports have had to add -L{$prefix}/lib to the LDFLAGS and -I$ {prefix}/include to the CFLAGS. Wouldn't it be much easier if the MacPorts infrastructure would add that to the LDFLAGS and CFLAGS generally for all ports? Could that hurt anything? I would think the same should apply to CPPFLAGS and/or CXXFLAGS, not that I have yet understood why there are two variables for C++ code or what the difference is between them.
On Mar 25, 2007, at 8:46 AM, Ryan Schmidt wrote:
Many ports have had to add -L{$prefix}/lib to the LDFLAGS and -I$ {prefix}/include to the CFLAGS. Wouldn't it be much easier if the MacPorts infrastructure would add that to the LDFLAGS and CFLAGS generally for all ports? Could that hurt anything?
I would think the same should apply to CPPFLAGS and/or CXXFLAGS, not that I have yet understood why there are two variables for C++ code or what the difference is between them.
I am working on a new mechanism that would allow that (and also fix some issues with universal variant, the fact that most ports in MacPorts are compiled with -O0, etc.) Paul
On Mar 24, 2007, at 18:53, Paul Guyot wrote:
On Mar 25, 2007, at 8:46 AM, Ryan Schmidt wrote:
Many ports have had to add -L{$prefix}/lib to the LDFLAGS and -I$ {prefix}/include to the CFLAGS. Wouldn't it be much easier if the MacPorts infrastructure would add that to the LDFLAGS and CFLAGS generally for all ports? Could that hurt anything?
I would think the same should apply to CPPFLAGS and/or CXXFLAGS, not that I have yet understood why there are two variables for C++ code or what the difference is between them.
I am working on a new mechanism that would allow that (and also fix some issues with universal variant, the fact that most ports in MacPorts are compiled with -O0, etc.)
Yes, I should have mentioned the -O0 problem too. And there's a related problem with the universal variant, that "-isysroot / Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc" is only added to the CFLAGS, not the CPPFLAGS and/or CXXFLAGS, and that this should be remedied. What is this new mechanism you're working on? I would have thought that MacPorts already somewhere defines what default environment variables to use, and that the -L and -I options could simply be added to it, without requiring any major reworking.
On Mar 25, 2007, at 12:46 AM, Ryan Schmidt wrote:
Many ports have had to add -L{$prefix}/lib to the LDFLAGS and -I$ {prefix}/include to the CFLAGS. Wouldn't it be much easier if the MacPorts infrastructure would add that to the LDFLAGS and CFLAGS generally for all ports? Could that hurt anything?
I would think the same should apply to CPPFLAGS and/or CXXFLAGS, not that I have yet understood why there are two variables for C++ code or what the difference is between them.
CPPFLAGS are for the preprocessor, they're unrelated to C++ Regards, Elias
On Mar 25, 2007, at 9:00 AM, Ryan Schmidt wrote:
What is this new mechanism you're working on? I would have thought that MacPorts already somewhere defines what default environment variables to use, and that the -L and -I options could simply be added to it, without requiring any major reworking.
Well, it doesn't and this is what I'm solving right now. I propose that I'll commit it after a couple of tests, and then we'll discuss: - if we should define default optimization/debug flags globally - the most beautiful way to handle universal variant Paul
On Mar 25, 2007, at 9:19 AM, Paul Guyot wrote:
On Mar 25, 2007, at 9:00 AM, Ryan Schmidt wrote:
What is this new mechanism you're working on? I would have thought that MacPorts already somewhere defines what default environment variables to use, and that the -L and -I options could simply be added to it, without requiring any major reworking.
Well, it doesn't and this is what I'm solving right now. I propose that I'll commit it after a couple of tests, and then we'll discuss: - if we should define default optimization/debug flags globally - the most beautiful way to handle universal variant
Done. Now that this change is committed: http://trac.macosforge.org/projects/macports/changeset/23098 we probably can consider adding -L${prefix}/lib and -I${prefix}/ include and clean up portfiles to avoid redundancy. Paul
On Mar 24, 2007, at 20:36, Paul Guyot wrote:
On Mar 25, 2007, at 9:19 AM, Paul Guyot wrote:
On Mar 25, 2007, at 9:00 AM, Ryan Schmidt wrote:
What is this new mechanism you're working on? I would have thought that MacPorts already somewhere defines what default environment variables to use, and that the -L and -I options could simply be added to it, without requiring any major reworking.
Well, it doesn't and this is what I'm solving right now. I propose that I'll commit it after a couple of tests, and then we'll discuss: - if we should define default optimization/debug flags globally - the most beautiful way to handle universal variant
Done. Now that this change is committed: http://trac.macosforge.org/projects/macports/changeset/23098
we probably can consider adding -L${prefix}/lib and -I${prefix}/ include and clean up portfiles to avoid redundancy.
Very interesting! In what version of MacPorts will that be released? I would think that we cannot clean up portfiles until the code is released to the general population. Including it with 1.4 would be ideal, since that's about to be released... but it should clearly be tested first, perhaps in a 1.4rc3 release, which should then bake for awhile. So this would delay the final release of 1.4 by a little bit. But I think it would be well worth it to finally be able to start making some headway on universal builds without having to duplicate so much stuff in the portfiles.
On Mar 24, 2007, at 19:02, Elias Pipping wrote:
On Mar 25, 2007, at 12:46 AM, Ryan Schmidt wrote:
Many ports have had to add -L{$prefix}/lib to the LDFLAGS and -I$ {prefix}/include to the CFLAGS. Wouldn't it be much easier if the MacPorts infrastructure would add that to the LDFLAGS and CFLAGS generally for all ports? Could that hurt anything?
I would think the same should apply to CPPFLAGS and/or CXXFLAGS, not that I have yet understood why there are two variables for C++ code or what the difference is between them.
CPPFLAGS are for the preprocessor, they're unrelated to C++
*That* is of course very interesting. I feel very silly for not knowing that. Thank you for clarifying.
On Mar 25, 2007, at 6:14 AM, Ryan Schmidt wrote:
In what version of MacPorts will that be released? I would think that we cannot clean up portfiles until the code is released to the general population. Including it with 1.4 would be ideal, since that's about to be released... but it should clearly be tested first, perhaps in a 1.4rc3 release, which should then bake for awhile. So this would delay the final release of 1.4 by a little bit. But I think it would be well worth it to finally be able to start making some headway on universal builds without having to duplicate so much stuff in the portfiles.
Sorry, but I beg to differ. I think 1.4 really shouldn't be delayed any more. Sounds like a good idea for 1.4.1, though, which could be released anytime after 1.4 is out. Regards, Elias
On Mar 24, 2007, at 23:27, Elias Pipping wrote:
On Mar 25, 2007, at 6:14 AM, Ryan Schmidt wrote:
In what version of MacPorts will that be released? I would think that we cannot clean up portfiles until the code is released to the general population. Including it with 1.4 would be ideal, since that's about to be released... but it should clearly be tested first, perhaps in a 1.4rc3 release, which should then bake for awhile. So this would delay the final release of 1.4 by a little bit. But I think it would be well worth it to finally be able to start making some headway on universal builds without having to duplicate so much stuff in the portfiles.
Sorry, but I beg to differ. I think 1.4 really shouldn't be delayed any more. Sounds like a good idea for 1.4.1, though, which could be released anytime after 1.4 is out.
Ok. I would just hate for it to have to wait for 1.5 which, since 1.4 is just being released, will probably be quite a long ways away.
participants (3)
-
Elias Pipping
-
Paul Guyot
-
Ryan Schmidt