<html> <head> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> </head> <body> <div>Hi Boris,<br /></div><div><br /></div><div>Once again, thanks a lot for your help and the time that you are spending on my questions.<br /></div><blockquote class="tutanota_quote" style="border-left: 1px solid #93A3B8; padding-left: 10px; margin-left: 5px;"><div>For example, you can create an amalgamation (see the create command<br /></div><div>in the b(1) man page) and place it in a repository. Then you just<br /></div><div>clone that repository and configure your project in it which will<br /></div><div>inherit the configuration from the amalgamation. The nice thing<br /></div><div>about this approach is that you can still override some settings<br /></div><div>during the configuration step and you can use the same amalgamation<br /></div><div>to build multiple projects (we do that a lot in our setup).<br /></div></blockquote><div>That sounds like a good plan, I will try it.<br /></div><blockquote class="tutanota_quote" style="border-left: 1px solid #93A3B8; padding-left: 10px; margin-left: 5px;"><blockquote><div>When using the version of build2 that you indicated, things are<br /></div><div>working fine as long as the content of a given implementation file<br /></div><div>(e.g. cde/cde_XXX.cpp) remains unused outside of its test driver<br /></div><div>(e.g. cde/cde_XXX-t.cpp).<br /></div></blockquote><div><br /></div><div>Well, to be fair, you never mentioned this requirement in your original<br /></div><div>email.<br /></div></blockquote><div>Sorry about this, I should have make it explicit in my first email.<br /></div><blockquote class="tutanota_quote" style="border-left: 1px solid #93A3B8; padding-left: 10px; margin-left: 5px;"><div>Yes, these are pretty much the alternatives. A build system could<br /></div><div>theoretically have a mode where it would detect that a source file<br /></div><div>includes header cde/cde_XXX.hpp, assume that it will also need<br /></div><div>cde/cde_XXX.cpp (which, BTW, could very well be an incorrect<br /></div><div>assumption -- think of inline functions), and then automatically<br /></div><div>link the corresponding object file. While I remember hearing someone<br /></div><div>doing it, this approach does feel pretty complex and ad hoc with<br /></div><div>quite a few assumptions.<br /></div></blockquote><div>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.<br /></div><blockquote class="tutanota_quote" style="border-left: 1px solid #93A3B8; padding-left: 10px; margin-left: 5px;"><blockquote><div>From the developer perspective though it could be helpful to have<br /></div><div>a way to run only the test drivers that were either updated since<br /></div><div>the last "build2 test" command or unsuccessful during the last run.<br /></div><div>I realize that this is not ideal because a test does not only depend<br /></div><div>on the associated binary but also (at least) on the associated<br /></div><div>"testscript" file and the files eventually referenced in this<br /></div><div>"testscript" file.<br /></div><div><br /></div><div>That being said, it would be nice to find a simple solution that<br /></div><div>covers a common use case where the test depends only on its<br /></div><div>associated binary and its associated "testscript" file. Would<br /></div><div>this be an acceptable solution to identify such kind of tests<br /></div><div>in the the buildfile using a special option and to have them<br /></div><div>processed accordingly by build2? The default behavior would<br /></div><div>remain the current one if the option is not set for a given<br /></div><div>test.<br /></div></blockquote><div><br /></div><div>I agree it would be nice but again all the possible solutions<br /></div><div>that come to mind seem very magicky. But let's see:<br /></div><div><br /></div><div>Tests that are executed via testscript have a working directory<br /></div><div>created for them. For successful tests this directory is<br /></div><div>automatically cleaned up but that can be suppressed (see<br /></div><div>config.test.output). So we could store some state in there.<br /></div><div>The biggest issue, as you have identified, is making sure<br /></div><div>that we keep track of everything that affects the test. We<br /></div><div>can handle the testscript (including everything that it<br /></div><div>includes automatically) automatically. As well as the target<br /></div><div>being tests (by just saving its timestamp). And for the rest<br /></div><div>we can require that you explicitly list all other dependencies<br /></div><div>as prerequisites of the target being tested (which you probably<br /></div><div>already do anyway if you want the dist operation to work). Yeah,<br /></div><div>maybe this can work.<br /></div></blockquote><div>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.<br /></div><blockquote class="tutanota_quote" style="border-left: 1px solid #93A3B8; padding-left: 10px; margin-left: 5px;"><div>BTW, not sure if you are aware, but you can already run individual<br /></div><div>testscript tests manually. See the description of the test module<br /></div><div>in build system manual for details.<br /></div></blockquote><div>I will try that for the time being as I imagine that with a growing number of tests this could otherwise become a bottleneck.<br /></div><div><br /></div><div>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.<br /></div><div><br /></div><div>Best<br /></div><div><br /></div> </body> </html>