kicad-developers team mailing list archive

[Michael Steinberg <michsteinb@xxxxxxxxx>]

Hello Wayne, and others too of course!

> I'm fine with copying the binaries to a single directory.  It's not very
> elegant but it's probably the path of least resistance.  I'm surprised
> cmake doesn't have a way to temporarily add build libs for testing
> purposes.  Maybe they do and I'm just not aware of it.  Please make sure
> you add any necessary hooks to clean up the shared test directory to the
> cmake config so as not to leave a bunch of orphaned binaries laying around.

CMake makes it easy to customize the output build directory per target or shared. That was the most help I was expecting really. If we set a variable this way, we build to a shared directory, otherwise we don't. The build system will then figure out if that means to only copy the stuff from the intermediate build directories, or a full rebuild is necessary. Also see the last paragraph.

> I would like finer test granularity as well.  It would also be nice if
> tests could be grouped so that you could run say all of the tests on
> libcommon as a group or each individual test within the libcommon group.
>   I don't know if boost::unit_test supports this but if it does that
> would be a good thing to implement.
I think we need to differ here on which level the granularity is 
intended to be. There's the CTest-level that works on "command" 
granularity. The executables themselves are linked to Boost.test, so you 
can specify which tests to run inside the executable as well.
CTest granularity could then be multiple executables: 
"libcommon.string", "libcommon.foo", "libcommon.bar". It could as well 
mean one executable but multiple runs of the same test-executable with 
different command line arguments.
I will investigate which if any possibilities there are to define suites 
per one executable in Boost.Test, or if test cases are the broadest 
thing there, just to get the picture complete. I only want to mention 
that CTest and Boost.Test are more or less complementing each other 
rather than doing the same thing and there's space to find the best 
combination for us.

I originally intended to actually build kicad into a shared directory on 
windows in development and test configurations (no need to run an extra 
install if they're directly built into a destination environment, so it 
helps the development cycle as well). So it would probably be a (c)make 
clean operation to purge the build in this case. What are the benefits 
of rather copying them around in a custom build step, since that seems 
so natural to you  that you take it as given?

Michael

PS: Sorry that the citing is not perfect, I copied from multiple sources.