CMake support #192
CMake support #192
Conversation
|
Thanks, @jollyroger. I'll test it on Mac OS X either this weekend or early next week. |
|
The |
|
Is there a reason to have in-source builds? If it would simplify anything, I would suggest supporting only out-of-source builds. |
|
I don't know the proper way to run Is that correct? It pollutes the top-level directory with more files, including |
|
I see that there's now a |
|
Since |
|
@spl, I'll update README.md. Meanwhile here is a short example of the in-source and out-of-source builds:
Could you please run make in the following way: This will expose all information about commands being run. There's a weird error you've spotted. According to your previous message with output of cmake, the gtest sources were found in thirdparty/gtest. But your compile command shows that gtest was not found. This could possibly mean that:
Could you please share last 15-20 lines of the failed build with VERBOSE=1? Concerning tests: they are built during normal |
|
@jollyroger Thanks for the explanation of the in-source vs. out-of-source builds. I see now that it's not a difference in the configuration but in how Is there an easy way to remove the extra build-related files after an in-source build? That's really a shame that Here is the verbose output ( It's not including the I see there's a difference with the In this case, |
| # for include directory separately from source directory. | ||
| FIND_PATH(GTEST_INCLUDE_DIR | ||
| NAMES gtest/gtest.h | ||
| PATH_SUFFIES include |
There was a problem hiding this comment.
Typo? I'm guessing it should be PATH_SUFFIXES.
|
@spl yes, that's a typo. Nice catch! However if Concerning the answers on StackOverflow: both have problems. The accepted answer uses different taget name (like |
* Support for both in-source and out-of-source builds * Set library version to 0.12 to map Debian package * Add separate options to build tests, examples and documentation * Add pkgconfig lookup support (if installed with `make install`) * Add CMake lookup support (if isntalled with `make install`) * Add Google Test Source lookup * Add CTest support for running tests (use `make test` or `ctest -V`)
|
@spl, I have rebased my branch against recent master, here are some changes:
|
|
I believe the instructions should use My build was successful this time, and The Thanks for the updates, @jollyroger! |
|
@spl, I didn't use this approach here because there's already $ mkdir ../build $ cd ../build $ cmake ../rapidjson $ make $ ctest -V $ sudo make install There is no problem in your approach if there would be no |
|
@jollyroger Fair enough. A couple of thoughts on that:
|
|
Regarding (3.) in @spl's last comment, I would suggest to update
|
|
@pah Good catch! |
|
@pah, @spl, I'm already working on CI in a separate However I wonder what is the default behaviour for running the tests. Current travis tests disable perftest for release builds and disable objdump check for debug builds. I'm sure most users will desire to run all available tests. I could add a separate option to enable all tests by default but make travis builds behave as before. Sounds ok? @pah, I've got question about current build procedure: why didn't you install doxygen with Also, cmake already builds doxygen documentation which makes a lot of code in |
Actually, it's the other way round for the current Travis configuration. And running For the defaults, I'm fine with running all tests locally.
Because the version currently available on the Travis machines via APT is not recent enough for the Markdown support we're relying on to generate the detailed user documentation.
No, it only makes the |
|
Some updates on travis configuration (see latest commits). Here is an example of successfull travis build: Also, currently it is possible to run unittests with valgrind enabled. However there is another way to acieve this using ctest's
|
|
Hello, what's the current status of this update? I like this comprehensive PR. I am eager to have this merged into the master branch. For now, I did my own flavor of CMake build system for my urgent needs (cf. https://github.com/davidok8/rapidjson/compare/maint-replace-premake-by-cmake). |
|
Hi @jollyroger, Conventionally if a software is going to be installed into a non-default prefix, only However, in current build of RapidJSON, I need to modify It is OK if this is exactly what you intend for. And it would be better to remind users to change these variables for a custom prefix. If you instead want to put all those files into the prefix specified by user, That is, use rather than In this way all |
|
@thebusytypist, I'm sorry for the late reply. Thank you for your well-thought comment. Yes, I intended this behaviour. It covers the common case when install prefix is set up during the first cmake run. This will calculate all other directoris according to their default values that depend on |
This is my try to add CMake support for RapidJSON and close #82. It was tested and is working for:
Some features available in this pull request:
make install)make testofctest -Vto get verbose output as before)As small addition: I fixed linking errors in the documentation.