having the "+test" or "+tests" variant propagate causes unexpected builds

[Daniel J. Luke]

I have the same situation in a port I maintain. 

I would like to be able to specify pre/post phase actions inside a phase block (so when running ‘port test’ a pre-configure that does the necessary setup will run)

I haven’t looked at base/ to see how I’d want to implement it, but I think the port files would look cleaner (and we wouldn’t need variant-specific magic), so complexity there seems worthwhile.  

--
Daniel J. Luke

> On Oct 30, 2022, at 6:23 AM, Ryan Schmidt <ryandesign at macports.org> wrote:
> 
> On Oct 28, 2022, at 21:33, Daniel J. Luke wrote:
>> 
>> I don't think implementation difficulty is the barrier here - but that all variants should just have the same behavior.
>> 
>> In my mind, the real problem is the need for +test variants, there should be a way to just use the test phase - and perhaps changes to base/ to enable that are a better option.
> 
> In one of my ports that has a tests variant, the reason why the variant exists is that the build system looks for certain test dependencies at configure time. If they're not there, it doesn't build the test suite and doesn't allow tests to be run later. I'm not sure how MacPorts could be improved to handle that better in the absence of a tests variant. Would you have MacPorts do the configuration in the configure phase, do the build in the build phase, and then redo the configuration and build in the test phase? Or would you suggest in this case that the test dependencies that are needed at configure time should be added unconditionally, so that even users who won't be running the tests need to install them? In my port's case the dependencies are probably small and that wouldn't make much of a difference, but I'm not sure it'll always be that way for all ports.
> 
>