Re: [26399] trunk/dports/math/nestedsums/Portfile
On Jun 21, 2007, at 00:53, source_changes@macosforge.org wrote:
Revision: 26399 http://trac.macosforge.org/projects/macports/changeset/26399 Author: gwright@macports.org Date: 2007-06-20 22:53:34 -0700 (Wed, 20 Jun 2007)
Log Message: ----------- Build only on darwin_8 or later. This eliminates the need for a macports g++ compiler, and since cln (a dependency via GiNaC) only works on darwin_8 or later, we don't lose anything.
Modified Paths: -------------- trunk/dports/math/nestedsums/Portfile
Modified: trunk/dports/math/nestedsums/Portfile =================================================================== --- trunk/dports/math/nestedsums/Portfile 2007-06-21 05:40:45 UTC (rev 26398) +++ trunk/dports/math/nestedsums/Portfile 2007-06-21 05:53:34 UTC (rev 26399) @@ -5,7 +5,7 @@ version 1.4.9 categories math platforms darwin -maintainers nomaintainer@macports.org +maintainers gwright@macports.org description nestedsums library long_description \ A Library for the Symbolic Expansion of a Class of \ @@ -21,9 +21,14 @@ #user_notes On Tiger (10.4.x), Xcode 2.1 is required to avoid a bug # in gcc which causes one of the tests to fail.
+platform darwin 6 { + ui_msg "nesteedsums is not supported on Jaguar (OS X 10.2.x)." + exit 1 +} + platform darwin 7 { - depends_build port:gcc40 - configure.env CXX=g++-dp-4.0 + ui_msg "nesteedsums is not supported on Panther (OS X 10.3.x)." + exit 1 }
default_variants +test
On Jun 21, 2007, at 00:58, source_changes@macosforge.org wrote:
Revision: 26400 http://trac.macosforge.org/projects/macports/changeset/26400 Author: gwright@macports.org Date: 2007-06-20 22:58:03 -0700 (Wed, 20 Jun 2007)
Log Message: ----------- Don't build on darwin 6 and 7 anymore. Since GiNaC depends on cln which doesn't build on these versions, we don't lose anything.
Modified Paths: -------------- trunk/dports/math/GiNaC/Portfile
Modified: trunk/dports/math/GiNaC/Portfile =================================================================== --- trunk/dports/math/GiNaC/Portfile 2007-06-21 05:53:34 UTC (rev 26399) +++ trunk/dports/math/GiNaC/Portfile 2007-06-21 05:58:03 UTC (rev 26400) @@ -40,12 +40,14 @@ depends_lib port:readline \ port:cln
+platform darwin 6 { + ui_msg "GiNaC is not supported on Jaguar (OS X 10.2.x)." + exit 1 +} + platform darwin 7 { - depends_build port:gcc40 - - configure.env CXX=g++-dp-4.0 \ - CPPFLAGS=-I${prefix}/include \ - LDFLAGS=-L${prefix}/lib + ui_msg "GiNaC is not supported on Panther (OS X 10.3.x)." + exit 1 }
platform darwin 8 {
But could you please not output messages and exit merely in a platform statement? Please do so only within a stage such as pre- fetch, e.g.: platfrom darwin 7 { pre-fetch { ui_msg "GiNaC is not supported on Panther (OS X 10.3.x)." exit 1 } } Otherwise, people running port info, portindex, etc. on darwin 7 will be inconvenienced by the exit.
On Jun 21, 2007, at 04:31, Ryan Schmidt wrote:
But could you please not output messages and exit merely in a platform statement? Please do so only within a stage such as pre- fetch, e.g.:
platfrom darwin 7 { pre-fetch { ui_msg "GiNaC is not supported on Panther (OS X 10.3.x)." exit 1 } }
Otherwise, people running port info, portindex, etc. on darwin 7 will be inconvenienced by the exit.
Sorry; I didn't see Chris already made these points.
On Jun 21, 2007, at 02:45, Ryan Schmidt wrote:
On Jun 21, 2007, at 04:31, Ryan Schmidt wrote:
But could you please not output messages and exit merely in a platform statement? Please do so only within a stage such as pre- fetch, e.g.:
platfrom darwin 7 { pre-fetch { ui_msg "GiNaC is not supported on Panther (OS X 10.3.x)." exit 1 } }
Otherwise, people running port info, portindex, etc. on darwin 7 will be inconvenienced by the exit.
Sorry; I didn't see Chris already made these points.
It really bears re-iterating though. Calling exit(1) in a Portfile is just bad news, at any stage. Maybe we should remove that procedure from the Portfile Tcl interpreter ... -landonf
On Jun 21, 2007, at 15:14, Landon Fuller wrote:
On Jun 21, 2007, at 02:45, Ryan Schmidt wrote:
On Jun 21, 2007, at 04:31, Ryan Schmidt wrote:
But could you please not output messages and exit merely in a platform statement? Please do so only within a stage such as pre- fetch, e.g.:
platfrom darwin 7 { pre-fetch { ui_msg "GiNaC is not supported on Panther (OS X 10.3.x)." exit 1 } }
Otherwise, people running port info, portindex, etc. on darwin 7 will be inconvenienced by the exit.
Sorry; I didn't see Chris already made these points.
It really bears re-iterating though. Calling exit(1) in a Portfile is just bad news, at any stage. Maybe we should remove that procedure from the Portfile Tcl interpreter ...
Well, true, but the only reason anyone's using it is to handle the situation where a port is incompatible with some OS version or some processor architecture. If we had a way of specifying that in the portfile syntax, then we wouldn't need to call exit. It would also have the advantage of standardizing the message that gets output to the user in these situations, rather than leaving it up to the portfile author in each case. Hmm.... Maybe platform darwin 7 { incompatible } ? Based on the auto-selected platform variant, MacPorts could then construct nice error strings. However, this wouldn't address an earlier concern of mine: why is a port incompatible with an OS? Is the OS too old or is it too new? We might have ports that need both situations. We could say platform darwin 7 { incompatible too_new } where the default is too_old. Or we could say platform darwin 7 { too_new } But that still doesn't tell the user which OS version(s) would be acceptable. Maybe we should think differently... not a platform variant, but some other directive: darwin.minimum 7 darwin.maximum 8 One could specify either or both (or none) of these. This would satisfy all variants, and would enable MacPorts to construct helpful messages to the user. ("Sorry, ${name} requires at least Mac OS X 10.3." or "Sorry, ${name} only works on Mac OS X 10.2 and earlier.") Doesn't address the processor architecture issue... that could still be platform i386 { incompatible } ("Sorry, ${name} is not compatible with Intel processors.") There could even be some options: platform i386 { incompatible temporary } ("Sorry, ${name} is not compatible with Intel processors at this time.") platform powerpc { incompatible permanent } ("Sorry, ${name} is not (and will never be) compatible with PowerPC processors.") Finally.... maybe we could still allow the port author to either add to or replace the default message. platform powerpc { incompatible permanent "Sorry, ${name} is written in Intel assembly code, so it cannot work on PowerPC processors." }
The fact that people want to do this (and I can kind of understand the desire to have a way of saying "Stop! This portfile will HURT YOUR BRAIN on OS foo/architecture bar/whatever") suggests the need for a ui_fatal procedure, however. That could then be conditionalized to do the right thing for interactive use only. - Jordan On Jun 21, 2007, at 1:14 PM, Landon Fuller wrote:
On Jun 21, 2007, at 02:45, Ryan Schmidt wrote:
On Jun 21, 2007, at 04:31, Ryan Schmidt wrote:
But could you please not output messages and exit merely in a platform statement? Please do so only within a stage such as pre- fetch, e.g.:
platfrom darwin 7 { pre-fetch { ui_msg "GiNaC is not supported on Panther (OS X 10.3.x)." exit 1 } }
Otherwise, people running port info, portindex, etc. on darwin 7 will be inconvenienced by the exit.
Sorry; I didn't see Chris already made these points.
It really bears re-iterating though. Calling exit(1) in a Portfile is just bad news, at any stage. Maybe we should remove that procedure from the Portfile Tcl interpreter ...
-landonf _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
That seems a lot more complicated than my ui_fatal procedure suggestion. :-) - Jordan On Jun 21, 2007, at 1:48 PM, Ryan Schmidt wrote:
On Jun 21, 2007, at 15:14, Landon Fuller wrote:
On Jun 21, 2007, at 02:45, Ryan Schmidt wrote:
On Jun 21, 2007, at 04:31, Ryan Schmidt wrote:
But could you please not output messages and exit merely in a platform statement? Please do so only within a stage such as pre- fetch, e.g.:
platfrom darwin 7 { pre-fetch { ui_msg "GiNaC is not supported on Panther (OS X 10.3.x)." exit 1 } }
Otherwise, people running port info, portindex, etc. on darwin 7 will be inconvenienced by the exit.
Sorry; I didn't see Chris already made these points.
It really bears re-iterating though. Calling exit(1) in a Portfile is just bad news, at any stage. Maybe we should remove that procedure from the Portfile Tcl interpreter ...
Well, true, but the only reason anyone's using it is to handle the situation where a port is incompatible with some OS version or some processor architecture. If we had a way of specifying that in the portfile syntax, then we wouldn't need to call exit. It would also have the advantage of standardizing the message that gets output to the user in these situations, rather than leaving it up to the portfile author in each case. Hmm.... Maybe
platform darwin 7 { incompatible }
? Based on the auto-selected platform variant, MacPorts could then construct nice error strings.
However, this wouldn't address an earlier concern of mine: why is a port incompatible with an OS? Is the OS too old or is it too new? We might have ports that need both situations. We could say
platform darwin 7 { incompatible too_new }
where the default is too_old. Or we could say
platform darwin 7 { too_new }
But that still doesn't tell the user which OS version(s) would be acceptable. Maybe we should think differently... not a platform variant, but some other directive:
darwin.minimum 7 darwin.maximum 8
One could specify either or both (or none) of these. This would satisfy all variants, and would enable MacPorts to construct helpful messages to the user. ("Sorry, ${name} requires at least Mac OS X 10.3." or "Sorry, ${name} only works on Mac OS X 10.2 and earlier.")
Doesn't address the processor architecture issue... that could still be
platform i386 { incompatible }
("Sorry, ${name} is not compatible with Intel processors.")
There could even be some options:
platform i386 { incompatible temporary }
("Sorry, ${name} is not compatible with Intel processors at this time.")
platform powerpc { incompatible permanent }
("Sorry, ${name} is not (and will never be) compatible with PowerPC processors.")
Finally.... maybe we could still allow the port author to either add to or replace the default message.
platform powerpc { incompatible permanent "Sorry, ${name} is written in Intel assembly code, so it cannot work on PowerPC processors." }
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
On 22 Jun, 2007, at 18:57, Jordan K. Hubbard wrote:
That seems a lot more complicated than my ui_fatal procedure suggestion. :-)
- Jordan
It's also a lot more complicated than method used in the portfile I linked to in my original message (fusefs [1]), which as you might note, already exhibits the proper behavior in interactive mode :) Chris [1] http://trac.macosforge.org/projects/macports/browser/trunk/dports/ fuse/fusefs/Portfile
On Jun 21, 2007, at 1:48 PM, Ryan Schmidt wrote:
On Jun 21, 2007, at 15:14, Landon Fuller wrote:
On Jun 21, 2007, at 02:45, Ryan Schmidt wrote:
On Jun 21, 2007, at 04:31, Ryan Schmidt wrote:
But could you please not output messages and exit merely in a platform statement? Please do so only within a stage such as pre-fetch, e.g.:
platfrom darwin 7 { pre-fetch { ui_msg "GiNaC is not supported on Panther (OS X 10.3.x)." exit 1 } }
Otherwise, people running port info, portindex, etc. on darwin 7 will be inconvenienced by the exit.
Sorry; I didn't see Chris already made these points.
It really bears re-iterating though. Calling exit(1) in a Portfile is just bad news, at any stage. Maybe we should remove that procedure from the Portfile Tcl interpreter ...
Well, true, but the only reason anyone's using it is to handle the situation where a port is incompatible with some OS version or some processor architecture. If we had a way of specifying that in the portfile syntax, then we wouldn't need to call exit. It would also have the advantage of standardizing the message that gets output to the user in these situations, rather than leaving it up to the portfile author in each case. Hmm.... Maybe
platform darwin 7 { incompatible }
? Based on the auto-selected platform variant, MacPorts could then construct nice error strings.
However, this wouldn't address an earlier concern of mine: why is a port incompatible with an OS? Is the OS too old or is it too new? We might have ports that need both situations. We could say
platform darwin 7 { incompatible too_new }
where the default is too_old. Or we could say
platform darwin 7 { too_new }
But that still doesn't tell the user which OS version(s) would be acceptable. Maybe we should think differently... not a platform variant, but some other directive:
darwin.minimum 7 darwin.maximum 8
One could specify either or both (or none) of these. This would satisfy all variants, and would enable MacPorts to construct helpful messages to the user. ("Sorry, ${name} requires at least Mac OS X 10.3." or "Sorry, ${name} only works on Mac OS X 10.2 and earlier.")
Doesn't address the processor architecture issue... that could still be
platform i386 { incompatible }
("Sorry, ${name} is not compatible with Intel processors.")
There could even be some options:
platform i386 { incompatible temporary }
("Sorry, ${name} is not compatible with Intel processors at this time.")
platform powerpc { incompatible permanent }
("Sorry, ${name} is not (and will never be) compatible with PowerPC processors.")
Finally.... maybe we could still allow the port author to either add to or replace the default message.
platform powerpc { incompatible permanent "Sorry, ${name} is written in Intel assembly code, so it cannot work on PowerPC processors." }
participants (4)
-
Chris Pickel
-
Jordan K. Hubbard
-
Landon Fuller
-
Ryan Schmidt