daniperez

thanks for the tip @twxs!

Your solution looks really simple! I must admit that my solution (as in the 3d article of the series) is quite "orthodox" in the sense that it uses the means provided by CMake for this purpose, yet I find it quite convoluted. I hope they improve that in the future.

By the way if you use the backtics with your code, other people will be able to read it and make the most of it ;-)

Hi Rajish!

I agree it's a bit confusing. In the article I describe 2 files: I'm talking all the time about the main CMakeLists.txt file except at the end that I mention foo-config.cmake.in. In any case, whereever I say "foo", you should replace that by the name of your project. Concretely, fooTargets.cmake is a file that is generated in CMake's binary project folder (where makefiles and other intermediate config files are written) and it's used by foo-config.cmake.in to locate our library targets. It will work regardless of configuring your project with in-source or installed libraries.

fixed! thanks @thonixx!

Fixed! After few hours writing "cmake" over and over again I didn't see the difference :-) Thanks!

I wrote a macro with that code. I didn't have time to add documentation and some "boundary" checks. An example of use can be found here (the write_config_file macro).

(Hopefully) the last article of these series written:
https://coderwall.com/p/qej45g

thanks for the tips! I've been using CMake for a while, only now I was trying to push it a bit further than usual. You can find my last experiments in the 'cmake-way' branch of my 'ortul' package†. It's a project I'm working on which depends on Google's OR-TOOL and lazylpsolver.

† the project is in its very early stages, I was only playing with packaging.

I totally agree with you. Too much boilerplate for something that should be easier. The thing I don't understand is the export(TARGETS) and install(EXPORT) asymmetry. I would prefer a single way of doing things. I wouldn't even mind if it's not flexible and maybe it doesn't cope with 100% of scenarii as long as it copes with a good majority. And using other libraries not installed in the system is one of them in my honest opinion.

I understand your pain if you, in addition to that mess, have to manage the git submodules as well :-) In my case, I let ExternalProject_Add download them for me, I found that easier than having to deal with git submodules.

About your last paragraph, I think every C++ programmer (including myself) has at least once wanted to have something like Maven for dependencies. I understand it's the C++'s Unicorn, but I think it can be feasible under some assumptions.

I find also very interesting how development will change as Docker evolves and improves. With Docker you set the Linux distro beforehand, so no more configuration step or multi-platform madness. And the dependencies are managed by the distribution (e.g. yum in Fedora). Looking forward to it :-)

I'll check GTest's build! Thanks!