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. R. _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
