Re: NO_TEST, do-test: and TEST_DEPENDS?

Am 24.05.22 um 17:27 schrieb Bjoern A. Zeeb:> On Sun, 22 May 2022, Stefan Esser
wrote:
> 
>> I'm not sure I understand the goal of your request.
> 
> the goal is to cut down dependencies and build time.

As long as you do not invoke the tests (with "make test"), no
dependencies will be built that are only required to run tests.

>> Do you want to have a switch that prevents the execution of tests when
>> "make test" explicitly asks for the tests to be run???
>>
>> This could easily be added to bsd.port.mk, but what for???
>>
>>> What is the proper way to
>>>     (1) disable tests
>>
>> That's what I do not understand ... Tests are not run by default, and
>> thus I never saw the need to disable them in any of my ports.
>>
>> Quite the opposite: If "make test" is invoked for a port that supports
>> tests, I definitely want them to be executed.
> 
> Right, so maybe solving (2) will solve (1) implicitly as I probably
> don't have to disable them then using .ifdef bits.

I still do not see the issue. TEST_DEPENDS are only relevant
if you specifically require them with "make test".

And no, not building the TEST_DEPENDS will only cause "make test"
to fail early due to unsatisfied build and/or run requirements, if
"make test" is invoked.

>>> and more important
>>>     (2) to amke sure the TEST_DEPENDS and not build in these cases?
>>
>> You can set "DO_MAKE_TEST=true" to execute the command "true" instead
>> of "make" when bsd.port.mk wants to execute the tests.
>>
>> But this is an undocumented internal variable of the ports system, and
>> it could be removed or renamed at any time, when changes are applied
>> to bsd.port.mk.
>>
>> And you could override the TEST_DEPENDS macro instead of wrapping it
>> into an .if block.
> 
> how?  putting
> .if defined(TEST_DEPENDS)
> .undef TEST_DEPENDS
> .endif
> or something like that in make.conf?

No, this has to be done in such a way that it can not later be
overridden by a definition in the port's Makefile.

>>> While I can iterate on port after port and apply a change like the below it
>>> feels utterly wrong and it seems I am doing something silly here which has a
>>> proper knob I cannot find?
>>
>> Please explain what you want to achieve. There may be other ways to
>> achieve your goal, but I think I do not understand what your goal is ...
> 
> Okay, for I have no idea anymore how long I've built the ports I need
> in the classical way; I have a "meta port" depending on the 25
> packages I need to build.

How is this meta-port implemented?

Do you just invoke "make all deinstall install" for each origin
from which a port has been installed?

Or do you collect all dependencies of each of the 25 ports in the
list and re-build and re-install all of them??

> The problem has bcome that rather than simple builds the amounts of
> ports build exploded.  With that the addition of conflicts has also
> exploded.  something people do probably not see (anymore these days)
> if their build depends conflict.

I see it all the time. The "poudriere" builds tend to not see nested
build conflicts, since build dependencies are installed from packages.
Therefore, a lot of them are not detected by maintainers.

And there are quite a number of ports that have "CONFLICTS" where
"CONFLICTS_INSTALL" would do. This is a non-issue when using poudriere,
since it does only care about direct conflicts (i.e. install conflicts
of build tools with each other and with the port being built).

Building from a port may cause indirect build dependencies to be in
conflict with each other and since they are not de-installed after use
(which would be possible for pure build dependencies), the conflicts
cause build failures.

> One larger contributor to the explosion is TEST_DEPENDS.  I'll give
> you an example.
> 
> cd dns/bind9 && env BATCH=yes NO_TEST= make all-depends-list

This origin does not exist, only bind9-devel, bind916, and bind918.
But I get your point, the generated list for bind9-devel has 472 entries.

But what I do not understand: why do you think that this list is of
relevance, if you do not run "make test"?

If you just count the dependencies that are actually built if you
do not run any tests, the list has 311 entries. Still quite a large
number, about 2/3 of the list including test dependencies.

> Feel free to disable DNSTAP DOCS and MANPAGES (manually) to avoid
> python for any of that (but there are different stories for another
> time).
> 
> Crazy, right?  It comes from TEST_DEPENDS mostly.  I still haven't all
> tracked down which include stuff which is never even used.

No, while TEST_DEPENDS accounts for 161 additional ports, there are
311 other dependencies.

You can remove TEST_DEPENDS from the definition of _UNIFIED_DEPENDS
on line 4024 of bsd.port.mk to exclude them from the output of
"make all-depends-list", if you never want to have them in this list.

> Sorry, the world is warm enough.. did we stop thinking again?

I really do not understand what you are doing ...

Are you forcefully rebuilding all ports in the all-depends-list each
time you decide to upgrade bind?

As I said: none of the TEST_DEPENDS will be built and installed,
unless you cause them to be built for "make test".

This is the purpose of TEST_DEPENDS: to only build those ports if
they will be required to execute the tests.

But if you actually forcefully rebuild all ports in all-depends-list,
then you are really wasting lots of cycles and energy.

Just use "portmaster -a" or "portupgrade" (with whatever option it
takes to update all outdated ports), they exist to streamline updating
ports on the base system.

These tools can install build dependencies from packages and remove
them again, when they are no longer required. They can build packages
with your set of options for deployment in jails or on other systems.

And they do of course only build or re-build ports that are actually
required, not tests unless you request tests to be run (-T option of
portmaster).

They are much easier to use than poudriere, but even poudriere can be
set up in a few minutes, and it builds ports in a clean environment
(and thus with less risk of side-effects of already installed ports).

It is of course possible to add a NO_TEST condition to bsd.port.mk to
make anything related to "make test" a NOP.

But not invoking "make test" if it is not desired has always been the
simpler solution for me.

Regards, STefan