[build2] publishing packages with external tests

[Boris Kolpackov]

Markus Pawellek <markuspawellek at gmail.com> writes:

> Boris Kolpackov <boris at codesynthesis.com> wrote:
> 
> > Generally, it is a good idea to publish at least the tests package so
> > that those who want to verify the functionality of the package can get
> > the extra dependencies and run the tests.
> >
> > Is there a reason why you would not want to publish them?
> 
> For now, it would be possible to publish the tests package.
> But at some time in the future, it may be possible that the build2 CI
> environment on cppget.org will not be able to completely build or
> execute the tests package due to new dependencies and requirements,
> like Boost or TestU01, which are currently not reachable by the
> build2 dependency toolchain.

Yes, I thought that would be the reason.

The recommended way to resolve this is to provide stub packages
for dependencies that haven't yet been packaged.

A stub is a package without any source code that can only be
"obtained" from the system (i.e., as a system-installed package).
Here is an example of a stub:

https://cppget.org/libapr1

As you can see, it has the special version 0.

The advantage of this approach is that you will be able to
publish your tests and those wanting to build and run them
will be able to do so by obtaining the stubbed dependencies
from the system. Also, if/when the stub is converted to a
real package, your packages will automatically be able to
take advantage of them.

It is, however, a bit of work to create and publish stubs
for your missing dependencies.


> In this case, I would remove the linking of the tests package from the
> library manifest file to keep on providing a package on cppget.org.

If you do this, I would recommend that you also provide at least
some basic tests for your package, probably as part of the package
itself (there is nothing wrong with having some extra dependency-free
tests in the package itself and additional tests as a separate *-tests
package).


> Hence, the old tests package would not be usable any longer.

Normally you would make the *-tests package version constraint
match the main package version exactly, for example:

tests: libbuild2-hello-tests == $

If done this way, you shouldn't have any issues changing your
mind on whether to publish the *-tests package.