[CMake] 'AUTOMOC' feature skips sources of executable targets?

Haroogan haroogan at gmail.com
Tue Apr 30 08:13:00 EDT 2013


On 30-Apr-13 08:40, Rolf Eike Beer wrote:
> Haroogan wrote:
>> On 29-Apr-13 23:27, Alexander Neundorf wrote:
>>> On Monday 29 April 2013, Haroogan wrote:
>>>> Have a look at my post on StackOverflow
>>>> <http://stackoverflow.com/questions/16286872/cmake-automoc-feature-skips-> >> so
>>>> urces-of-executable-targets> for details.
>>>> <http://stackoverflow.com/questions/16286872/cmake-automoc-feature-skips-> >> so
>>>> urces-of-executable-targets>
>>> can you please create a small testcase and post it here, or create an
>>> entry on http://public.kitware.com/Bug and attach it there ?
>>>
>>> It should work.
>> I've found the cause, and I think that's very confusing behavior. I'll
>> try to do my best explaining it.
>>
>> Let's begin with top 'CMakeLists.txt':
>>
>> ...
>>
>> set(CMAKE_INCLUDE_CURRENT_DIR ON)
>> set(CMAKE_AUTOMOC ON)
>>
>> ...
>>
>> # NOTE: Order matters (the most independent ones go first)
>> # because some libraries expose variables through cache (see below).
>> add_subdirectory(components/B)
>> add_subdirectory(components/A)
>>
>> add_subdirectory(components/Executable)
>>
>> So imagine that we have the 'FindMyPrecious.cmake' custom CMake module
>> to locate 3rd party framework "MyPrecious":
>>
>> find_package(Qt4
>>                4.7.4
>>                COMPONENTS QtCore
>>                           QtGui
>>                           QtXml
>>                REQUIRED)
>>
>> find_path(MyPrecious_INCLUDE_DIR...)
>>
>> find_library(MyPrecious_LIBRARY_DEBUG...)
>>
>> find_library(MyPrecious_LIBRARY_RELEASE...)
>>
>> set(QT_DEFINITIONS ${QT_DEFINITIONS}
>>                      -DQT_CORE_LIB
>>                      -DQT_GUI_LIB
>>                      -DQT_XML_LIB)
>>
>> if (CMAKE_BUILD_TYPE MATCHES [Dd][Ee][Bb][Uu][Gg])
>>     set(QT_DEFINITIONS ${QT_DEFINITIONS}
>>                        -DQT_DEBUG)
>> else ()
>>     set(QT_DEFINITIONS ${QT_DEFINITIONS}
>>                        -DQT_NO_DEBUG)
>> endif ()
>>
>> set(MyPrecious_DEFINITIONS ${QT_DEFINITIONS})
>>
>> set(MyPrecious_INCLUDE_DIRS ${MyPrecious_INCLUDE_DIR}
>>                               ${QT_INCLUDE_DIR}
>> ${QT_QTCORE_INCLUDE_DIR}
>> ${QT_QTGUI_INCLUDE_DIR}
>> ${QT_QTXML_INCLUDE_DIR})
>>
>> set(MyPrecious_LIBRARY debug     ${MyPrecious_LIBRARY_DEBUG}
>>                          optimized ${MyPrecious_LIBRARY_RELEASE})
> cmake --help-module SelectLibraryConfigurations
>
>> # -------------------------------
>> # ATTENTION: Theoretically, I don't have to add the line below.
>> # -------------------------------
>> # find_package(MyPrecious REQUIRED)
> You have to. If you don't the non-cached variables like QT_VERSION* are not
> present in this scope. No Qt, no automoc. And everything else may only work by
> pure luck.
>
> Also you should read the warning about file(GLOB) in the documentation.
>
> Eike
> -- 
>
>
> --
>
> 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://www.cmake.org/mailman/listinfo/cmake
Thank you for clarifying this. What would you recommend? Shall I find Qt 
explicitly or implicitly (like with "MyPrecious") in every subproject, 
and not rely on transitive dependency technique all at once? What is 
sort of the best practice?

Concerning GLOB, yes, I'm aware of that, but to be honest this warning 
doesn't make sense at all since:

 1. I think it is evident to everyone that CMake can capture those files
    only during the configuration/generation stage;
 2. What's the point of recommending against it? Either one adds sources
    by hand or one does it with GLOB - one has to rerun CMake anyway.
    However, with GLOB one doesn't have to add sources manually.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20130430/0fabd015/attachment.htm>


More information about the CMake mailing list