On May 11, 2015, at 12:51 AM, René J.V. Bertin <[email protected]> wrote:
> On Saturday May 09 2015 06:47:02 Ryan Schmidt wrote: > >> I don't understand... why would you build documentation in post-activate? >> why is this situation so unusual that normal MacPorts procedures cannot >> accommodate it? > > The point is that if I couple this documentation too tightly to the port it > documents, you get a situation where it is rebuilt each time the port is > updated, even if that's just a revision bump to force a rebuild against some > changed dependency. That's overkill which carries a cost I don't want. That > was one of the reasons why I initially thought of making the generation > dependent on an env. variable. However, if documentation is not rebuilt every > time, you cannot have it installed through the usual destroot, because then > it would not be present anymore after the previous version/build has been > deactivated. > > It's true I could create a subport that drops part of the main ports > versioning, for instance so that 4.14.x.y becomes 4.14 . That's something > that can be captured rather easily in tcl code. Still, after looking a bit > more at the actual generation process, I'm beginning to think I'd be using an > external script anyway. I don't even know yet exactly what it will take to > generate the monolithic .qch file I have in mind, but it could well be > needlessly complex to do that in inline tcl code. And from there it's just a > small step to install such a script (along with the main port) so that > interested users can invoke it directly themselves. I think I follow and admire your desire to not over burden the user/system with superfluous builds. Regards, Bradley Giesbrecht (pixilla)
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
