Hi Tamás,
On Mon, Jan 25, 2016 at 7:02 PM, Tamás Kenéz <tamas.ke...@gmail.com> wrote: > Gonzalo, Ray, > > I think your approaches are not in accordance with some CMake best practices > (or at least what I believe they are). Thank you for looking over my web site! I welcome comments since I am learning as I go along and I also don't know what "CMake best practices" are. There seems to be a lot of flexibility and a lot of ways to get things wrong. > Please take a look at Ray's example after a heavy refactor: > https://github.com/tamaskenez/cmake-2016-jan-21-shared-lib-exe Thanks for refactoring it! I just realized I probably should have put my example on GitHub. Perhaps I'll do it instead of having just a tar.gz file. > These are the things I changed: > > - In your test executables don't compile the source files of the > library-under-test into your test. Instead, link to the library. Reason (1) > ODR, (2) this way you'll test the linking operation, too. That's an excellent point! Thanks! > - Don't reach out from a subdirectory ('B') to include a sibling ('A'). It > creates harmful coupling between the subdirectories. All information that > 'B' needs to know about 'A' should be concentrated in the properties of the > target 'A'. So you need to use commands like target_include_directories(). > - Unnecessary verbosity makes it harder to read and debug the CMakeLists. The verbosity was a bit on purpose. To help others follow the example and to help me follow months after I look at it! But, another reason is that I have many CMakeLists.txt that are very similar. And the only part that is different are the filenames. So, I do copy and paste my CMakeLists.txt and change just all the filenames in one place. Perhaps it is hard to read and debug, but when almost all of my CMakeLists.txt are the same, then it is actually a bit easier. > - you can build and test 'A' standalone > - you can build and test 'A', 'B' and 'X' in one project using the top-level > CMakeLists.txt > - you can't build 'B' standalone or can't build 'X' without 'A' and 'B' > being there. If you need that feature, we need to add an install step to 'A' > and 'B' and use find_package() in 'B' and 'X' on demand Hmmmmm, I see. However, the last point isn't what I was trying to achieve. And I mentioned it on the "Summary" page. I was playing with this for a long time and did try what you suggest above. But, in one project, I had tree-like dependencies that stretched for more than two levels. (i.e., it wasn't just X needed A, X needed B, X needed C, etc.). So, I could have installed them into the system, but I only needed it to compile X and cluttering a user's system with libraries didn't seem like a good idea. BUT, I now see a way around it. I suppose I can install them into an install path within the build tree. And apply find_package () to just within the build tree. That would satisfy all of these criteria: 1) A and B are independent, 2) B can be built stand-alone, 3) A and B are installed within the build tree, 4) A and B are to be found with find_package (), and 5) Only X is installed in the system-level directory (since that is the only program that a user should run). I think this sounds fine... I will give it a try. Thank you for your comments! Ray -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
