On 02/06/2013 08:27 PM, Stephen Kelly wrote: > I've pushed a branch with some addtional fixes for various issues in > generator expressions.
Thanks, those all look good. I presume you're finding these by trying to use the new features for Qt5, KDE, and Boost? How else? > One of the issues relates to depends information in the build dir. I fixed > the situation in the makefile generator by expanding the COMPILE_DEFINITIONS > before writing out the DependsInfo.cmake file. Good catch. > The Ninja generator doesn't > use such a file, but from my porcelain test it seems to already detect the > INTERFACE content appropriately. I didn't check how that works. The Ninja generator depends on the toolchain to support "gcc -M" style flags so it always computes the dependencies that the compiler sees. The Makefile generators are the only ones that implement their own dependency scanning rather than relying on the native build tools. > It occurs to me though that this could be not just one bug but a class of > bugs. A similar issue could exist for the other generators, and anywhere > else that cmake generates 'buildsystem artifacts' which make need to be > evaluated as generator expressions, or may need to take INTERFACE content of > dependencies into account. Every generator expression should be evaluated as it passes through the generators before being written out to disk anywhere for the native build system to see. Are you asking whether there could be places that the expressions still leak through by accident? If so, I guess users will discover them soon enough ;) The most likely source of such bugs would be interfaces whose generation is re-implemented by each generator rather than passing through a central evaluation point. If such a case is discovered then the best fix would be to re-factor things to centralize the relevant evaluations. > Another possible candidate is <target>_LIB_DEPENDS in the cache. Currently, > cmTarget::AddLinkLibrary aborts if a generator expression is found before > populating that cache variable. Is that appropriate? Those variables are purely historical and should not be populated with any new interfaces. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
