On Jul 2, 2021, at 05:51, René J.V. Bertin wrote: > On Friday July 02 2021 04:31:50 Ryan Schmidt wrote: > >> If I create a dummy portfile that includes the python portgroup then then >> immediately tries to print destroot.pre_args, it shows why it failed: > > Yes, I followed that much. > >> The real question is why do you need to access destroot.pre_args right after >> including the python portgroup and before setting name? > > No, the real question is in reading the one I asked a little bit less > literally:
Well I can't guess what your real question was; I can only answer the ones you ask. >>> Why would `name` have to be defined in order to be able to evaluate >>> destroot.pre_args ? > > i.e. why would you do anything in a Portgroup that introduces this > side-effect. For instance, can't whatever it does be done in a pre-destroot > block, or via a callback (using a function that ? I am not certain whether changing that would introduce new unwanted side effects. The python portgroup is included in a *lot* of portfiles, so it might be difficult to verify that a change doesn't break one of them. > To answer your question: this came up because of a `destroot.pre_args-prepend > -v` statement I added to another Portgroup (local copy of the meson PG I've > been trying to improve). It seems perfectly reasonable to ensure (via its > dedicated PG) that a build system uses verbose mode in a build phase. By the same argument as in the preceding paragraph, you could do your `destroot.pre_args-prepend -v` modification in a pre-destroot block. > I've worked around the issue by doing the prepend only when the Python PG > hasn't been included (I could have added "and `name` isn't set yet) but it'd > be really nice if PGs tried their best to interfere least with others... They do. Sometimes situations, like the one you encountered, aren't anticipated.
