generating extra documentation (port:kdelibs4)

René J.V. Bertin rjvbertin at gmail.com
Fri May 8 06:01:16 PDT 2015


On Friday May 08 2015 07:23:17 Ryan Schmidt wrote:

>No, it would not be acceptable for a port to build differently based on an environment variable, because port builds should be repeatable and predictable and should not depend on aspects of the users environment.

Well, I know the rule, but they need exceptions to be confirmed, no? :) Seriously, I agree with that statement, but not where env. variables are concerned that exist explicitly to control the way a port builds ... as long as the result remains repeatable and predictable.

Come to think of it, in this case the documentation build would probably have to go in the post-activation phase (or wherever configuration files are created when not present yet) because what I had in mind clearly cannot go into the destroot . And I don't even know if ${workpath} is still around in that phase, if not set to be preserved.

The alternative and probably most elegant approach would be to install a script that does something like

- figure out the variants used in the active install
- port configure kdelibs4 [+variants]
- generate the documentation
- install it in an appropriate place

step 2 would be void if the user didn't auto-clean after the install, and in that case the documentation would really be built with the code that went into the current libraries.

R.


More information about the macports-dev mailing list