On 12/7/2016 1:05 PM, Michael Steinberg wrote: > 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?
In the end, I don't care how it is handled but `make clean` should clean up the test binaries as well. If it's handled automatically by cmake, all the better. If not, then you will have add cmake code to clean up the test code. > > Michael > > PS: Sorry that the citing is not perfect, I copied from multiple sources. > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
