-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Do not even add the testing executables when the tests are disabled. #9
base: master
Are you sure you want to change the base?
Conversation
I think this should be a more complex option to allow every possibility which was available previously, but for now, it'll do it for me: * If I want to build the test suite, it'll build it * If I don't need it (most of the time), it'll completely ignore test targets Focus is on the second point, as most of the CMake configuration time was spent on the test targets. With this change, build file generation only takes a few seconds.
Yea, we probably need a way to control whether tests are added or not, I am not sure the best way to do that yet. One, I would like to be able to have tests be able to run without reconfiguring cmake if the dependencies are satisfied. The is probably only useful in a standalone build where the number of tests are small. Secondly, I would like to be able to support partial checkouts of boost for building and testing. Someone only wants to test one library, so when We also need to support users who will use boost through For IDE users, is there some property that can be set to better organize tests when they are shown in the IDE? For developers that are using Boost with tests and an IDE, there should be a better way its presented in the GUI. |
Yes, I am trying to use this as a subdirectory for building boost libraries in CMake projects, and the tests took far more time up than anything else. And anytime I changed any of my CMakeLists, it ran for several minutes again. In those projects, I am not interested in the results of the boost test suite. With this change, it's just a few seconds.
USE_FOLDERS and the FOLDER property. Supports even nested structures with the usual directory separators.
This can be checked by using the PARENT_DIRECTORY property. So maybe use this "do not add the tests by default" behavior if it's a subproject? |
I'm very interested in not running tests by default. Most libraries that I've used have an explicit target like My use case is for cross compiling. Any progress on this? |
Thats the exactly how this works. However, the targets are still added, but not to the all target, which lets you run the tests without reconfiguring cmake(like what most projects do). The issue:
I think the solution is to use an |
The tests are currently targets excluded by the default target, so they aren't built.
But excluded targets are still generated, and created.
This has two results:
I simply reused the
BUILD_TESTING
option to not even include the test directories if it's not set. As you also used the off setting for some different behavior, I do not think this will be the correct/final solutions to it, but I do think that an option to disable them (and making that a default) would make the project more usable for end users.