[build2] Build2 configuration for component based projects

[asatsuyu at tutanota.com]

Hi Boris,

Once again, thanks a lot for your help and the time that you are spending on my questions.

> For example, you can create an amalgamation (see the create command
> in the b(1) man page) and place it in a repository. Then you just
> clone that repository and configure your project in it which will
> inherit the configuration from the amalgamation. The nice thing
> about this approach is that you can still override some settings
> during the configuration step and you can use the same amalgamation
> to build multiple projects (we do that a lot in our setup).
>
That sounds like a  good plan, I will try it.

>> When using the version of build2 that you indicated, things are
>> working fine as long as the content of a given implementation file
>> (e.g. cde/cde_XXX.cpp) remains unused outside of its test driver
>> (e.g. cde/cde_XXX-t.cpp).
>>
>
> Well, to be fair, you never mentioned this requirement in your original
> email.
>
Sorry about this, I should have make it explicit in my first email.

> Yes, these are pretty much the alternatives. A build system could
> theoretically have a mode where it would detect that a source file
> includes header cde/cde_XXX.hpp, assume that it will also need
> cde/cde_XXX.cpp (which, BTW, could very well be an incorrect
> assumption -- think of inline functions), and then automatically
> link the corresponding object file. While I remember hearing someone
> doing it, this approach does feel pretty complex and ad hoc with
> quite a few assumptions.
>
Finding a proper solution to this problem (which is obviously not specific to build2) does not look easy. For the header files, the compiler provides the list of dependencies as a by-product of the compilation. I am not sure about it but maybe the linker could help for object file dependencies.

>> From the developer perspective though it could be helpful to have
>> a way to run only the test drivers that were either updated since
>> the last "build2 test" command or unsuccessful during the last run.
>> I realize that this is not ideal because a test does not only depend
>> on the associated binary but also (at least) on the associated
>> "testscript" file and the files eventually referenced in this
>> "testscript" file.
>>
>> That being said, it would be nice to find a simple solution that
>> covers a common use case where the test depends only on its
>> associated binary and its associated "testscript" file. Would
>> this be an acceptable solution to identify such kind of tests
>> in the the buildfile using a special option and to have them
>> processed accordingly by build2? The default behavior would
>> remain the current one if the option is not set for a given
>> test.
>>
>
> I agree it would be nice but again all the possible solutions
> that come to mind seem very magicky. But let's see:
>
> Tests that are executed via testscript have a working directory
> created for them. For successful tests this directory is
> automatically cleaned up but that can be suppressed (see
> config.test.output). So we could store some state in there.
> The biggest issue, as you have identified, is making sure
> that we keep track of everything that affects the test. We
> can handle the testscript (including everything that it
> includes automatically) automatically. As well as the target
> being tests (by just saving its timestamp). And for the rest
> we can require that you explicitly list all other dependencies
> as prerequisites of the target being tested (which you probably
> already do anyway if you want the dist operation to work). Yeah,
> maybe this can work.
>
I am not found of magicky solutions as well, you have a better view on all this but that would be a nice feature (even in a limited form) to have in a future release.

> BTW, not sure if you are aware, but you can already run individual
> testscript tests manually. See the description of the test module
> in build system manual for details.
>
I will try that for the time being as I imagine that with a growing number of tests this could otherwise become a bottleneck.

Before ending this email, I would like to thank you and your team for all the work done on the build2 project. I have long been hoping for an easier/better way of handling build automation  and I have little doubt that build2 will play a role in that area.

Best

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.build2.org/archives/users/attachments/20171117/6f2a2c3d/attachment.html>