Hi list! I'm working on a CMake buildsystem for the Panda3D project. The project is essentially a C++ 3D engine with its own custom Python binding generator known as Interrogate. The basic idea is that after a library's C++ code is compiled in the usual way, the C++ source files and headers are passed to Interrogate which parses a (very large) subset of the C++ language and generates suitable C++ to bind the library to the CPython API. This is then compiled into a CPython extension module and linked against the C++ code.
Because Interrogate is invoked in much the same way as a compiler, and as such needs to know the include search path, I use a generator expression to read the INTERFACE_INCLUDE_DIRECTORIES target property for the library in question and produce -I flags for Interrogate. So far, so good. But again, Interrogate only knows a subset of C++, and while the Panda3D core is written with this in mind, this is a problem for third-party header files which might go outside of this subset. To solve this, the Panda3D source repository contains a "parser-inc" directory which contains stubbed-out header files solely intended for Interrogate. This means *hiding* the third-party package paths from Interrogate when it walks over INTERFACE_INCLUDE_DIRECTORIES. "No problem," I thought, "generator expressions do exactly that." So I wrote a generator expression that looks at the highest target and, if it has the IS_INTERROGATE property, hides it. However, when it came time to actually set this IS_INTERROGATE property, I could find no way to apply it to a custom command. I guess this makes sense - custom commands aren't targets, after all. But I couldn't convert my custom command to a custom target, because it produces a C++ source file and I need to use OUTPUT to let CMake know where that source file comes from, and you can't use OUTPUT and TARGET together in add_custom_command. At the end of the day, I ended up using this <https://github.com/panda3d/panda3d/commit/23996559206445a8016032d207bfbea320ff088e> as my workaround. It's really quite awful, and I'm not happy at all about the idea of maintaining it, but it does get the job done. *Thus, *my two questions are: 1) Is there a less messy way of accomplishing what I'm trying to do (that works in CMake 2.8.12+)? and 2) If not, should CMake be given an informational generator expression going forward that can determine context when targets aren't involved? Or put another way, "Am I missing something, or is this actually a shortcoming in CMake?" Thank you for your time, and I hope you're having a good day, Sam
-- 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: https://cmake.org/mailman/listinfo/cmake
