Re: [28325] trunk/dports/graphics/wxWidgets-devel/Portfile
On Aug 28, 2007, at 05:18, source_changes@macosforge.org wrote:
Revision: 28325
[snip]
@@ -66,7 +66,7 @@ --enable-monolithic
platform darwin 8 { - configure.env-append CC=/usr/bin/gcc-4.0 CPP=/usr/bin/cpp-4.0 CXX=/usr/bin/g++-4.0 + configure.compiler gcc-4.0 }
set installtype release
Why do we keep repeating these lines in so many portfiles? Why isn't "configure.compiler gcc-4.0" the default on darwin 8, and similarly, "configure.compiler gcc-3.3" the default on darwin 7?
Ryan Schmidt wrote:
Why do we keep repeating these lines in so many portfiles? Why isn't "configure.compiler gcc-4.0" the default on darwin 8, and similarly, "configure.compiler gcc-3.3" the default on darwin 7?
+1 If nothing else, it keeps those pesky "+darwin_8" variants alive. :-( --anders
Le 30 août 07 à 19:40, Anders F Björklund a écrit :
Ryan Schmidt wrote:
Why do we keep repeating these lines in so many portfiles? Why isn't "configure.compiler gcc-4.0" the default on darwin 8, and similarly, "configure.compiler gcc-3.3" the default on darwin 7?
+1
If nothing else, it keeps those pesky "+darwin_8" variants alive. :-(
--anders
I don't even understand why there is a default compiler hard written in ports. gcc-4 is the default on Tiger, users who change this behaviour surely know some things may break. -- Anthony Ramine, the infamous MacPorts Trac slave. nox@macports.org
On Aug 31, 2007, at 09:21, N_Ox wrote:
Le 30 août 07 à 19:40, Anders F Björklund a écrit :
Ryan Schmidt wrote:
Why do we keep repeating these lines in so many portfiles? Why isn't "configure.compiler gcc-4.0" the default on darwin 8, and similarly, "configure.compiler gcc-3.3" the default on darwin 7?
+1
If nothing else, it keeps those pesky "+darwin_8" variants alive. :-(
I don't even understand why there is a default compiler hard written in ports. gcc-4 is the default on Tiger, users who change this behaviour surely know some things may break.
Don't be so sure. The user population of Mac OS X is not like those of other UNIX-like operating systems. Users who use Linux and *BSD and similar operating systems have, I presume, chosen to do so because they are programmers or system administrators or similar who do not mind that the OS is a bit difficult to use, or don't even think it is difficult to use. They understand the system, understand the implications of what they do, understand how to write scripts, and have a basic understanding of what a compiler is and does. With Mac users, you should not assume these things. I don't mean to suggest that Mac users aren't smart; what I mean is that the Mac was introduced as being "the computer for the rest of us" [1] -- the computer for those who don't want or need to know how the computer works, but who just want to get their work done. And if that work involves installing some tool, then such users will look for a tutorial that explains how to do it. And if that tutorial tells them to "gcc_select 3.3" before compiling the software, the user will happily do just that, without knowing what implications it will have. The implications are apparently that on Tiger, many ports fail to build, leading the authors of hundreds of ports to include directives in their portfiles explicitly specifying gcc-4.0 on Tiger. (At least, that is the only reason I can think of for all these "platform darwin 8" sections appearing.) I'm arguing that we should remove these directives from the hundreds of ports where they currently appear, and instead put it in MacPorts base so that all 4200+ ports can benefit. [1] http://en.wikipedia.org/wiki/ List_of_Apple_Inc._slogans#Company_advertising_campaigns
On 31.08.2007, at 16:21, N_Ox wrote:
Le 30 août 07 à 19:40, Anders F Björklund a écrit :
Ryan Schmidt wrote:
Why do we keep repeating these lines in so many portfiles? Why isn't "configure.compiler gcc-4.0" the default on darwin 8, and similarly, "configure.compiler gcc-3.3" the default on darwin 7?
+1
If nothing else, it keeps those pesky "+darwin_8" variants alive. :-(
--anders
I don't even understand why there is a default compiler hard written in ports. gcc-4 is the default on Tiger, users who change this behaviour surely know some things may break.
The problem is that a user can use 'gcc_select' and you have no idea what 'gcc' .. executes on 10.4; if you know that your port is happy with any of the two, dont use a platform statement. If you dont want or dont can (e. g. on x86) to test your port with both compilers, state explicitly which one you know it compiles with. I have no idea what will happen to every single port if we tell port to automatically select a compiler if none is requested explicitly (though we can have a try). Regards, -Markus --- Markus W. Weissmann http://www.mweissmann.de/ http://www.macports.org/
On 01.09.2007, at 13:20, Weissmann Markus wrote:
On 31.08.2007, at 16:21, N_Ox wrote:
Le 30 août 07 à 19:40, Anders F Björklund a écrit :
Ryan Schmidt wrote:
Why do we keep repeating these lines in so many portfiles? Why isn't "configure.compiler gcc-4.0" the default on darwin 8, and similarly, "configure.compiler gcc-3.3" the default on darwin 7?
+1
If nothing else, it keeps those pesky "+darwin_8" variants alive. :-(
--anders
I don't even understand why there is a default compiler hard written in ports. gcc-4 is the default on Tiger, users who change this behaviour surely know some things may break.
The problem is that a user can use 'gcc_select' and you have no idea what 'gcc' .. executes on 10.4; if you know that your port is happy with any of the two, dont use a platform statement. If you dont want or dont can (e. g. on x86) to test your port with both compilers, state explicitly which one you know it compiles with. I have no idea what will happen to every single port if we tell port to automatically select a compiler if none is requested explicitly (though we can have a try).
'portconfigure.tcl' from trunk will chose a default for darwin 7/8/9 (gcc3.3/4.0/4.0). Please test it! Just replacing /opt/local/share/ macports/Tcl/port1.0/portconfigure.tcl with http://svn.macports.org/ repository/macports/trunk/base/src/port1.0/portconfigure.tcl manually should do the trick. This version also fixes a bug that when using configure.compiler every user-added compiler selection (e.g. 'configure.cc /bin/true') was overwritten. -Markus --- Markus W. Weissmann http://www.mweissmann.de/ --- Markus W. Weissmann http://www.mweissmann.de/
On Sep 1, 2007, at 6:07 AM, Weissmann Markus wrote:
'portconfigure.tcl' from trunk will chose a default for darwin 7/8/9 (gcc3.3/4.0/4.0). Please test it! Just replacing /opt/local/ share/macports/Tcl/port1.0/portconfigure.tcl with http:// svn.macports.org/repository/macports/trunk/base/src/port1.0/ portconfigure.tcl manually should do the trick.
This version also fixes a bug that when using configure.compiler every user-added compiler selection (e.g. 'configure.cc /bin/true') was overwritten.
This is going to break ports that require a different compiler, but specify the compiler using configure.env, or arguments to configure via configure.args. It's a shame that there are no auto-builds, as we don't know what will break. At the very least, would you be opposed to a new flag that enables (or disables) this behavior? -landonf
On Sep 1, 2007, at 06:20, Weissmann Markus wrote:
On 31.08.2007, at 16:21, N_Ox wrote:
Le 30 août 07 à 19:40, Anders F Björklund a écrit :
Ryan Schmidt wrote:
Why do we keep repeating these lines in so many portfiles? Why isn't "configure.compiler gcc-4.0" the default on darwin 8, and similarly, "configure.compiler gcc-3.3" the default on darwin 7?
+1
If nothing else, it keeps those pesky "+darwin_8" variants alive. :-(
I don't even understand why there is a default compiler hard written in ports. gcc-4 is the default on Tiger, users who change this behaviour surely know some things may break.
The problem is that a user can use 'gcc_select' and you have no idea what 'gcc' .. executes on 10.4; if you know that your port is happy with any of the two, dont use a platform statement. If you dont want or dont can (e. g. on x86) to test your port with both compilers, state explicitly which one you know it compiles with.
(I'm speaking of Tiger users here, which should be most of us:) I really don't think that any port authors, for every update of every port that they maintain, try it once with gcc 4 and once with gcc 3.3. Rather, I think they probably just try it with the default compiler selected on their machine, which would hopefully be gcc 4. By your logic, then, every such port should have gcc 4 listed in the darwin 8 section, to show that that's what it's been tested with. So, instead of that, it would be much better to do it globally at the MacPorts level, since it's reasonable to assume that ports on Tiger have been tested with Tiger's default compiler. Only ports that deviate from this (for example, the rare port that still requires gcc 3.3 on Tiger) should have to indicate this.
I have no idea what will happen to every single port if we tell port to automatically select a compiler if none is requested explicitly (though we can have a try).
Let's work through some scenarios then. Let us assume that the ports about which we're talking currently compile correctly and work. (If they don't, then the ports need to be updated anyway.) Assume there is a port that does not indicate what compiler it requires. On a standard Tiger system where gcc 4 is selected, it will currently use gcc 4. If we now change MacPorts so that gcc 4 is used on Tiger in preference to whatever gcc_select says, nothing changes. The port continues to use gcc 4 and continues to work. Using the same port, let's assume some user has used gcc_select to select gcc 3.3 without understanding the implications. They build this port. It happens to work. Great, no problem. If we change MacPorts so that gcc 4 is the default, the port continues to work. Great. Using the same port and the same user who selected gcc 3.3, let's assume the port fails to build under gcc 3.3. In this case, with current MacPorts, the port fails and the user complains. If we change MacPorts to use gcc 4 as the default, the port would instead work, and the user would be happy. So this is a reason to change MacPorts as I indicated. Let's move on to a different port, one that explicitly lists gcc 4 for Tiger. In all scenarios, there is no change. Whether the user has gcc 4 or gcc 3.3 selected, the port works, because it explicitly asks for gcc 4. Great. And let's look at yet another port, one that explicitly lists gcc 3.3 for Tiger. In all scenarios, there is no change. Whether the user has gcc 4 or gcc 3.3 selected, the port works, because it explicitly asks for gcc 3.3. To sum up: if we make gcc 4 the default for ports on Tiger, nothing changes for ports that explicitly request a different compiler. Nothing changes for users who already have gcc 4 selected, which should be most people. The only thing that changes is that users who have for some reason selected gcc 3.3, and for ports that do not specify a compiler, these ports will use gcc 4 instead of gcc 3.3. And this is a good thing, because gcc 4 is probably what the port author tested with. And so the port has a greater chance of working correctly for the user. And then we can also remove the "gcc 4" selections from the darwin 8 variants of all ports where that occurs, since that's redundant, and it's good to remove redundancy.
On Sep 1, 2007, at 12:45, Landon Fuller wrote:
On Sep 1, 2007, at 6:07 AM, Weissmann Markus wrote:
'portconfigure.tcl' from trunk will chose a default for darwin 7/8/9 (gcc3.3/4.0/4.0). Please test it! Just replacing /opt/local/ share/macports/Tcl/port1.0/portconfigure.tcl with http:// svn.macports.org/repository/macports/trunk/base/src/port1.0/ portconfigure.tcl manually should do the trick.
This version also fixes a bug that when using configure.compiler every user-added compiler selection (e.g. 'configure.cc /bin/ true') was overwritten.
This is going to break ports that require a different compiler, but specify the compiler using configure.env, or arguments to configure via configure.args.
Then we should start cleaning ports. All those that specify a different compiler via configure.env should be updated to use configure.cc, etc. Those that use configure.args (or build.args I've also seen) should... I don't know, be tested to see if they can instead use configure.cc (or build.cc, etc.; do we have that?).
It's a shame that there are no auto-builds, as we don't know what will break.
At the very least, would you be opposed to a new flag that enables (or disables) this behavior?
On 01.09.2007, at 22:52, Ryan Schmidt wrote:
On Sep 1, 2007, at 12:45, Landon Fuller wrote:
On Sep 1, 2007, at 6:07 AM, Weissmann Markus wrote:
'portconfigure.tcl' from trunk will chose a default for darwin 7/8/9 (gcc3.3/4.0/4.0). Please test it! Just replacing /opt/local/ share/macports/Tcl/port1.0/portconfigure.tcl with http:// svn.macports.org/repository/macports/trunk/base/src/port1.0/ portconfigure.tcl manually should do the trick.
This version also fixes a bug that when using configure.compiler every user-added compiler selection (e.g. 'configure.cc /bin/ true') was overwritten.
This is going to break ports that require a different compiler, but specify the compiler using configure.env, or arguments to configure via configure.args.
Then we should start cleaning ports. All those that specify a different compiler via configure.env should be updated to use configure.cc, etc. Those that use configure.args (or build.args I've also seen) should... I don't know, be tested to see if they can instead use configure.cc (or build.cc, etc.; do we have that?).
Indeed. "configure.env" is not officially supported anymore anyway... some ports cant do without, but most can. Please everybody clean your ports.
It's a shame that there are no auto-builds, as we don't know what will break.
At the very least, would you be opposed to a new flag that enables (or disables) this behavior?
Not at all. If it doesn't break anything by default, feel free to add it! Regards, -Markus --- Markus W. Weissmann http://www.mweissmann.de/
On Sep 2, 2007, at 12:11, Weissmann Markus wrote:
On 01.09.2007, at 22:52, Ryan Schmidt wrote:
On Sep 1, 2007, at 12:45, Landon Fuller wrote:
On Sep 1, 2007, at 6:07 AM, Weissmann Markus wrote:
'portconfigure.tcl' from trunk will chose a default for darwin 7/8/9 (gcc3.3/4.0/4.0). Please test it! Just replacing /opt/ local/share/macports/Tcl/port1.0/portconfigure.tcl with http:// svn.macports.org/repository/macports/trunk/base/src/port1.0/ portconfigure.tcl manually should do the trick.
This version also fixes a bug that when using configure.compiler every user-added compiler selection (e.g. 'configure.cc /bin/ true') was overwritten.
This is going to break ports that require a different compiler, but specify the compiler using configure.env, or arguments to configure via configure.args.
Then we should start cleaning ports. All those that specify a different compiler via configure.env should be updated to use configure.cc, etc. Those that use configure.args (or build.args I've also seen) should... I don't know, be tested to see if they can instead use configure.cc (or build.cc, etc.; do we have that?).
Indeed. "configure.env" is not officially supported anymore anyway... some ports cant do without, but most can. Please everybody clean your ports.
Why isn't configure.env supported anymore? The new guide documents this option, and does not mention anything about it being deprecated or unsupported. If it is unsupported, the guide should state that, and recommend alternatives. http://geeklair.net/new_macports_guide/#reference.keywords.configure
Ryan Schmidt wrote:
On Sep 2, 2007, at 12:11, Weissmann Markus wrote:
On 01.09.2007, at 22:52, Ryan Schmidt wrote:
On Sep 1, 2007, at 12:45, Landon Fuller wrote:
On Sep 1, 2007, at 6:07 AM, Weissmann Markus wrote:
'portconfigure.tcl' from trunk will chose a default for darwin 7/8/9 (gcc3.3/4.0/4.0). Please test it! Just replacing /opt/local/share/macports/Tcl/port1.0/portconfigure.tcl with http://svn.macports.org/repository/macports/trunk/base/src/port1.0/portconfi... manually should do the trick.
This version also fixes a bug that when using configure.compiler every user-added compiler selection (e.g. 'configure.cc /bin/true') was overwritten.
This is going to break ports that require a different compiler, but specify the compiler using configure.env, or arguments to configure via configure.args.
Then we should start cleaning ports. All those that specify a different compiler via configure.env should be updated to use configure.cc, etc. Those that use configure.args (or build.args I've also seen) should... I don't know, be tested to see if they can instead use configure.cc (or build.cc, etc.; do we have that?).
Indeed. "configure.env" is not officially supported anymore anyway... some ports cant do without, but most can. Please everybody clean your ports.
Why isn't configure.env supported anymore?
Yes, the qt3-mac port needs it, and actually, the it's been broken for a while due to the configure.env and build.env not honoring it. If somebody could fix MacPorts (and not the Portfile) to honor it, I would appreciate it. See this ticket for information on when the *.env broke: http://trac.macports.org/projects/macports/ticket/11895 Regards, Blair -- Blair Zajac, Ph.D. CTO, OrcaWare Technologies <blair@orcaware.com> Subversion training, consulting and support http://www.orcaware.com/svn/
On 03.09.2007, at 02:43, Ryan Schmidt wrote:
On Sep 2, 2007, at 12:11, Weissmann Markus wrote:
On 01.09.2007, at 22:52, Ryan Schmidt wrote:
On Sep 1, 2007, at 12:45, Landon Fuller wrote:
On Sep 1, 2007, at 6:07 AM, Weissmann Markus wrote:
'portconfigure.tcl' from trunk will chose a default for darwin 7/8/9 (gcc3.3/4.0/4.0). Please test it! Just replacing /opt/ local/share/macports/Tcl/port1.0/portconfigure.tcl with http:// svn.macports.org/repository/macports/trunk/base/src/port1.0/ portconfigure.tcl manually should do the trick.
This version also fixes a bug that when using configure.compiler every user-added compiler selection (e.g. 'configure.cc /bin/true') was overwritten.
This is going to break ports that require a different compiler, but specify the compiler using configure.env, or arguments to configure via configure.args.
Then we should start cleaning ports. All those that specify a different compiler via configure.env should be updated to use configure.cc, etc. Those that use configure.args (or build.args I've also seen) should... I don't know, be tested to see if they can instead use configure.cc (or build.cc, etc.; do we have that?).
Indeed. "configure.env" is not officially supported anymore anyway... some ports cant do without, but most can. Please everybody clean your ports.
Why isn't configure.env supported anymore?
oops - sorry, my fault! I really wanted to say: Using configure.env directly should be avoided - we do have a nice set of commands for setting the most used flags at configuration time. If you cannot do without, of course it is still supported.
The new guide documents this option, and does not mention anything about it being deprecated or unsupported. If it is unsupported, the guide should state that, and recommend alternatives.
http://geeklair.net/new_macports_guide/#reference.keywords.configure
Well yes. We should probably though put our manpages online, too and clearly state that if in doubt the manpage is right. -Markus --- Markus W. Weissmann http://www.mweissmann.de/
On Sep 2, 2007, at 19:51, Blair Zajac wrote:
Ryan Schmidt wrote:
On Sep 2, 2007, at 12:11, Weissmann Markus wrote:
Indeed. "configure.env" is not officially supported anymore anyway... some ports cant do without, but most can. Please everybody clean your ports.
Why isn't configure.env supported anymore?
Yes, the qt3-mac port needs it, and actually, the it's been broken for a while due to the configure.env and build.env not honoring it.
If somebody could fix MacPorts (and not the Portfile) to honor it, I would appreciate it.
See this ticket for information on when the *.env broke:
I'd still like to hear Paul's input on this.
Weissmann Markus <mww@macports.org> writes:
Why isn't configure.env supported anymore?
oops - sorry, my fault! I really wanted to say: Using configure.env directly should be avoided - we do have a nice set of commands for setting the most used flags at configuration time. If you cannot do without, of course it is still supported.
The new guide documents this option, and does not mention anything about it being deprecated or unsupported. If it is unsupported, the guide should state that, and recommend alternatives.
http://geeklair.net/new_macports_guide/#reference.keywords.configure
Well yes. We should probably though put our manpages online, too and clearly state that if in doubt the manpage is right.
I personally find the man pages less than adequate. They were built piecemeal, and therefore they lack overall coherence; they are just lists with less structure than they should have. I intend to make the guide as authoritative as possible, at least as much as the current man pages. And I am striving for more coherently structured information in the new guide than in the old one or the man pages. If that can be accomplished, perhaps the man pages should be reformatted in DocBook and then they could be regened into man pages daily as is the guide, and then xincluded into the guide's reference section so as not to maintain duplicate source docs. Or at least that seems feasilbe by considering portfile.7 anyway. If we got that far I would also want to have a scratchpad where base committers past their preliminary doc additions for review and inclusion by the doc team. No more permanent doc changes in the middle of the night 5 minutes after hacking on base. Otherwise the docs just degrade over time as entropy sets in. Sounds good on paper anyway. Comments welcome. Mark
On 03.09.2007, at 11:05, markd@macports.org wrote:
Weissmann Markus <mww@macports.org> writes:
Why isn't configure.env supported anymore?
oops - sorry, my fault! I really wanted to say: Using configure.env directly should be avoided - we do have a nice set of commands for setting the most used flags at configuration time. If you cannot do without, of course it is still supported.
The new guide documents this option, and does not mention anything about it being deprecated or unsupported. If it is unsupported, the guide should state that, and recommend alternatives.
http://geeklair.net/new_macports_guide/#reference.keywords.configure
Well yes. We should probably though put our manpages online, too and clearly state that if in doubt the manpage is right.
I personally find the man pages less than adequate. They were built piecemeal, and therefore they lack overall coherence; they are just lists with less structure than they should have. I intend to make the guide as authoritative as possible, at least as much as the current man pages. And I am striving for more coherently structured information in the new guide than in the old one or the man pages. If that can be accomplished, perhaps the man pages should be reformatted in DocBook and then they could be regened into man pages daily as is the guide, and then xincluded into the guide's reference section so as not to maintain duplicate source docs. Or at least that seems feasilbe by considering portfile.7 anyway. If we got that far I would also want to have a scratchpad where base committers past their preliminary doc additions for review and inclusion by the doc team. No more permanent doc changes in the middle of the night 5 minutes after hacking on base. Otherwise the docs just degrade over time as entropy sets in. Sounds good on paper anyway. Comments welcome.
Having only one place for documentation sounds great! I suppose regenerating the manpages for every release only could be sufficient. -Markus --- Markus W. Weissmann http://www.mweissmann.de/
Weissmann Markus <mww@macports.org> writes:
Having only one place for documentation sounds great! I suppose regenerating the manpages for every release only could be sufficient.
Yes I suppose so. I was forgetting that if hte man pages were in DocBook, there would be two regens; one for the html guide reference pages, and one for the man pages themselves. The latter could be done at each release. Mark
participants (7)
-
Anders F Björklund
-
Blair Zajac
-
Landon Fuller
-
markd＠macports.org
-
N_Ox
-
Ryan Schmidt
-
Weissmann Markus