On Apr 10, 2007, at 08:20, Daniel J. Luke wrote:
On Apr 10, 2007, at 2:48 AM, Ryan Schmidt wrote:
If I do that, how can I avoid each port (php5-apache2, php5- fastcgi, etc.) having to download the php5 source again?
By setting distname and dist_subdir
(like the apr port used to do to share the apache2 distfile:
http://trac.macports.org/projects/macports/browser/trunk/dports/ devel/apr/Portfile?rev=5083
)
Thanks for that! I was sure I had seen that somewhere before, I just couldn't quite remember where.
I'm not sure that making separate ports is the best strategy. The FastCGI version of PHP is not a separate software package. Rather, it's just one of the many ways in which PHP can be installed. It's a variation, a variant. And it seems most logical that it be implemented in MacPorts in that way, as a variant.
of course, the downside of variants is that nothing can depend on them being there (which is why, for instance, the various subversion bindings ports are not implemented as variants, even though the current setup requires lots of extra build time which is otherwise unnecessary).
So wouldn't we most accurately call that a deficiency in base that should be corrected, rather than bastardizing the portfiles to work around the deficiency? :)
Isn't there a way in tcl to detect if a certain function exists?
I'm not sure if there is ... I would have to look it up.
... but even if there was, the point Landon was trying to make (I think) was that that was private/internal API that ports shouldn't be using. If there's really no good way to do what needs to be done some other way with the portfile, then we should enhance base/ to provide hooks for it instead of using command_exec.
I note, by the way, that there are several other ports already using the "command" command, which will break when MacPorts 1.5 (or whatever version) is released which removes the "command" command:
dports $ grep '\[command' */*/Portfile aqua/radassist/Portfile: system "[command patch] < \"$ {workpath}/patch-darwinports\"" devel/curlhandle/Portfile: system "[command build]" devel/libsdl-framework/Portfile: system "[command build]" net/nefu/Portfile: system "[command build]" textproc/gpsbabel/Portfile: system "[command build]"
These should probably be fixed.
First problem is that the only one of those ports that has a maintainer is gpsbabel. Does anyone care about the other ports? Someone who cares will have to be the one to fix them. Let me take a quick look at why they're using this syntax:
aqua/radassist/Portfile: system "[command patch] < \"$ {workpath}/patch-darwinports\""
Yeah, that's awful. It would take a bit of work to fix. It looks like a large number of non-MacPorts paths are hardcoded into this project, and the patchfile combined with a reinplace and this system command are trying to replace them with the correct MacPorts prefix.
devel/curlhandle/Portfile: system "[command build]"
It looks like it's calling build a second time to build a second item ("Tester").
devel/libsdl-framework/Portfile: system "[command build]"
It looks like it's using Xcode to build the target "Framework", then build again with the target "All". Can the xcode portgroup help here?
net/nefu/Portfile: system "[command build]"
It seems to build once in the main directory, then build again in the subdirectory "TDK".
textproc/gpsbabel/Portfile: system "[command build]"
Not sure exactly what's going on but it seems to be doing a lot of Xcode trickery too. xcode portgroup again?