Skip to content
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

Unit test fails when doing a CMake out-of-tree build #241

Closed
ChrisKitching opened this issue May 8, 2016 · 3 comments
Closed

Unit test fails when doing a CMake out-of-tree build #241

ChrisKitching opened this issue May 8, 2016 · 3 comments

Comments

@ChrisKitching
Copy link
Contributor

This occurs because it looks for the test data in paths relative to the source tree. Since the test target is not installed, and the test data is not present in the build tree, this fails.

I would suggest making a CMake build option to allow turning off the unit tests, and then making the test data and test binary be installed to the install tree in the conventional way. In-tree builds are, after all, discouraged.

@nlohmann
Copy link
Owner

nlohmann commented May 8, 2016

Hi @ChrisKitching! I only have limited knowledge of CMake and only used it to create a MSVC project for AppVeyor. As my library is header-only, I am not sure why anyone would actually use "my" CMakeLists.txt file, anyway. Before making any changes to it, I would like to understand the benefits for it.

@nlohmann nlohmann added kind: enhancement/improvement state: please discuss please discuss the issue or vote for your favorite option labels May 8, 2016
@ChrisKitching
Copy link
Contributor Author

ChrisKitching commented May 8, 2016

As you know, the cmake script you have builds the tests and then installs the header.

Some plausible uses of this script (my use-case, too, incidentally):

Pulling in your library as a CMake ExternalProject dependency

Even though it's header only, there's still value in pulling it via ExternalProject as it is made explicit which version of your library is used. If I copied the header into my own source control system it becomes "detached" from this git repo, which is potentially irritating. It's useful to be able to say in my build script "use the v1.1.0 tag of nlohmann/json", rather than having to fiddle about making sure I've copied the right version of your header into my source control.
While ExternalProject doesn't require CMake, it's very slightly neater if it is, especially because of the next thing...

Verifying cross-compilation

By building it as an external project, it can be made to automatically pick up the cross-compile flags used in the parent build. This means that if I cross compile my project, I'll automatically end up causing your cmake script to emit a cross-compiled test binary, which will allow me to verify that your library doesn't catch fire when run on whatever silly embedded system I'm using.

Certainly, though, not a big priority. I'm probably going to end up doing this work myself at some point quite soon. If you're interested I'll make a pull request.

@nlohmann
Copy link
Owner

nlohmann commented May 8, 2016

I see. Yes, a PR would be nice. For me, the most important thing is that compiling the unit tests would remain the standard, because otherwise I would have to adjust AppVeyor.

If it is not too much to ask, it would be great if you could double check whether the current Cmakelists.txt is OK and whether it actually has to be that long ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants