[build2] Execute a test of a library with a macro enabled

artur.brzozowski artur.brzozowski at protonmail.com
Wed Nov 27 11:43:59 UTC 2024


Hi, Boris.

Thank you for helping out with pointers and the rationale.

> https://build2.org/build2-toolchain/doc/build2-toolchain-packaging.xhtml#howto-debug-macro

Following the procedure given on the Packaging Guide page, I managed to arrive
at a solution I was looking for.

I think I see your point and this manual approach, e.g.

``` shell
$ b configure config.libsomething.trace=true -v test
```

is more than acceptable, and again, actually quite "hygenic" and elegant.

I will be definitely sticking around.

Best wishes,
Artur

On Monday, November 25th, 2024 at 8:20 AM, Boris Kolpackov <boris at codesynthesis.com> wrote:

> artur.brzozowski via users users at build2.org writes:
> 
> 
> 
> > I am trying out build2 and I have to say the first impression is that
> > of a very elegant tool.
> 
> 
> Thank you, I am glad to hear that.
> 
> > Libsomething has some conditional compilation done with a preprocessor macro
> > (say, `#ifdef TRACE`) in "something.hxx". I want to have TRACE defined for
> > libsomething when I run `b test`.
> > 
> > ``` shell
> > $ cat libsomething/tests/basics/buildfile
> > import libs = libsomething%lib{something}
> > 
> > cxx.poptions += -DTRACE ## ADDED
> > 
> > exe{driver}: {hxx ixx txx cxx}{**} $libs
> > ```
> > 
> > Simply adding the `cxx.poptions`, like above, does not seem to enable
> > TRACE for libsomething for testing.
> 
> 
> Right, this will define TRACE when compiling the test driver, but not
> the imported library.
> 
> And this is by design since, at least in the general case, consumers
> of the library imposing arbitrary (and potentially incompatible)
> configuration on the library is not something that we would want.
> 
> As an example, imagine libsomething is imported by another project (say,
> an application that uses it) and both the tests and this project are
> built simultaneously (which is common in build2). Now, because the tests
> enabled tracing, the application will also end up using libsomething
> with tracing, which is probably not something that we want, at least
> not implicitly like this.
> 
> Instead, the recommended way of dealing with something like this is
> to make it explicit via a configuration variable. There is a section
> in the packaging guide with some background:
> 
> https://build2.org/build2-toolchain/doc/build2-toolchain-packaging.xhtml#howto-debug-macro
> 
> With this approach, if you want to stick with the build2 build system
> only, then you will need to configure your project with tracing enabled
> manually. But if you want to wade into packaging, then we have support
> for packages negotiating the desired configuration of their dependencies.
> With this mechanism, you could create a separate tests package that
> automatically configures libsomething with tracing enabled. See this
> HOWTO article on separate tests packages:
> 
> https://github.com/build2/HOWTO/blob/master/entries/handle-tests-with-extra-dependencies.md



More information about the users mailing list