René J.V. Bertin rjvbertin at gmail.com
Wed Jan 14 07:10:08 PST 2015

On Wednesday January 14 2015 13:06:01 Mojca Miklavec wrote:

> There might be one, but that doesn't really help us to make the
> package(s). 

To be very honest, I seem to recall that the script kind of makes packaging unnecessary because it downloads everything required without doing (too many) redundant things.

> It is helpful for the creator of the Portfile to know
> which steps are needed, but one cannot just use a script
> out-of-the-box.

No, not OOTB. But a Portfile can invoke a script if things get too complicated/cumbersome to do from Tcl, and inversely, an existing script can be modified to do part through installing/upgrading ports (scripts can test if a port exists with certain variants ;)) and it can be installed itself through a port...

> (Talking about libgcc compile time ... I believe it must take over 24
> hours to compile libgcc on iBook G4 and then it breaks anyway. Then
> Jeremy updates files, so another day ... and so on. I've been trying
> to install a working compiler on Leopard since Sunday; no success
> yet.)

Are you still working on a G4 system? Ouch ... (though I guess my slowboat Linux netbook must be about that "fast")

> time it took for granted. All I remember is that it was looooooooooong
> and that I could have avoided much of the compilation time if I could
> repeat the compilation from the same tree.)

Yes, I know. Even on a 2.7Ghz i7 from 2011 it takes too long to wait for it.

> making things inefficient ;) Then again it's still better to have a
> non-optimized installation that gets you the result than not having
> the software available in the first place.


You know, that hypothetical script from above might just be able to do the optimisation you're after. I routinely get port to rebuild only the necessary parts by hacking the .macports state file. (I must have about 50Gb of build directories online ATM, between 2 Qt versions, the Calligra build suite and the KDE ports I'm tinkering with...)
Nothing can prevent a script from doing an initial setup for that port E that could re-use the build directory from port C (say, `port patch E`) and then replace the contents of its build directory with that from port C (except for the state file of course). It'll take a bit of trial and error before it works, and it'll require constant maintenance, but it's not impossible.
And yes, it won't be the most user-friendly experience to install mingw64 that way, but I guess that anyone even interested in a cross-compiler is going to be able to follow instructions.

Alternatively, if my memory about the provided script is correct, it could be invoked such that it does what every port does: do a "fake install" in ${destroot}, and then a real install from there. If that doesn't involve a non-distributable product, the buildbots will take care of the time-consuming process.


More information about the macports-dev mailing list