Re: [cmake-developers] Setting the link interface and dependencies in one command
Stephen Kelly wrote: > > Hi David, > > This is related to my patch to set the link_interface_libraries to empty > and to: > > http://thread.gmane.org/gmane.comp.kde.devel.buildsystem/6622/focus=72030 > > Quoting: > >> Setting LINK_INTERFACE_LIBRARIES to empty is still needed and wanted. >> By default, all libraries a target is linked agaonst are in the >> LINK_INTERFACE, which leads to unnecessary dependencies and increased >> load time. >> The alternative would be not to set it to empty, and expect our >> developers to take care of it. I think this is not realistic. >> So I'm quite sure we still want that > > > David Cole wrote: >> I'm going to say wait until Brad replies here, but I do not see a >> problem with that, *if* it's actually necessary. (Other than the >> obvious problem, which is that LINK_INTERFACE and >> LINK_INTERFACE_LIBRARIES are very close to each other and people will >> get them confused, and constantly be looking at the documentation to >> try to figure out which is which... A distinguishing naming >> difference, if you could come up with one, would be better. i.e., >> names where you can tell what the meaning is for each, without >> referring to the documentation...) > > set_target_libraries(foo > bar baz > LINK_DEPENDENCY_LIBRARIES > bat mar > ) > > So bat and mar do not become part of the link interface libraries? > > This is analogous to the IMPORTED_LINK_DEPENDENCY_LIBRARIES I think. > The sideline discussion about linking seems to be finished, so I'm bumping the idea of being able to specify both the non-exposed dependencies and the exposed dependencies in one command without repetition. I see three options: 1) Change the meaning of LINK_INTERFACE_LIBRARIES in set_target_properties(foo LINK_INTERFACE_LIBRARIES bar) to not just communicate that users of foo should also link against bar, but make that command actually link foo against bar. I don't know if there is any use case for the existing behaviour. This could be done with a CMake policy. It would then be very trivial to make set_target_properties(foo baz LINK_INTERFACE_LIBRARIES bar) mean 'foo links against baz, but doesn't expose symbols from it; foo links against bar, and does export symbols from it'. 2) Introduce another variable for doing the same thing as above. As David notes, this might be confusing without looking up docs (though it wouldn't be the first part of CMake that needs docs to use). Also, if the existing behaviour of LINK_INTERFACE_LIBRARIES (do not actually link to the things listed there) doesn't have a use-case, or is rare, that one would fall out of use, and the new one would be more commonly used (it is good to optimise for the common case). 3) Introduce a variable for doing the opposite of what LINK_INTERFACE_LIBRARIES does. That is, the equivalent of the above would be set_target_properties(foo bat LINK_DEPENDENT_LIBRARIES baz) (note that bat and baz are swapped). This form communicates that baz should be linked against foo, but users of foo do not need to link against baz. My preference is (1). Does anyone know the reason for the current behaviour? Thanks, Steve. -- 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
Re: [cmake-developers] Setting the link interface and dependencies in one command
Brad King wrote: > On 10/4/2011 10:22 PM, Stephen Kelly wrote: >> 1) Change the meaning of LINK_INTERFACE_LIBRARIES in >> >> set_target_properties(foo LINK_INTERFACE_LIBRARIES bar) > > Do you mean target_link_libraries, rather than set_target_properties? > The latter is a very general command and will not be taught special > behavior for certain properties. I'm assuming you mean > >target_link_libraries(foo LINK_INTERFACE_LIBRARIES bar) Yes, you are correct. Thanks for the clarification. > >> 2) Introduce another variable for doing the same thing as above. > > s/variable/keyword argument to target_link_libraries/ > >> My preference is (1). > > We need to use (2) with a well-chosen name. > Thanks for all of your explanations. It seems that introducing a way to do this with one command has some support. So if SOME_FEATURE is true, target_link_libraries(foo bar SOME_KEYWORD baz) if (SOME_FEATURE) target_link_libraries(foo mar SOME_KEYWORD maz) endif() would have to result in bar and mar not being part of the link interface, and baz and maz being part of the link interface. How do we decide on a keyword there? LINK_INTERFACE_DEPENDENCIES perhaps? All the best, Steve. -- 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
Re: [cmake-developers] Setting the link interface and dependencies in one command
Brad King wrote:
> On 10/5/2011 9:47 AM, Stephen Kelly wrote:
>> Thanks for all of your explanations. It seems that introducing a way to
>> do this with one command has some support.
>>
>> So if SOME_FEATURE is true,
>>
>> target_link_libraries(foo bar SOME_KEYWORD baz)
>> if (SOME_FEATURE)
>>target_link_libraries(foo mar SOME_KEYWORD maz)
>> endif()
>>
>> would have to result in bar and mar not being part of the link interface,
>> and baz and maz being part of the link interface.
>>
>> How do we decide on a keyword there? LINK_INTERFACE_DEPENDENCIES perhaps?
>
> One possible problem with making it a keyword is that the name could
> appear in a list of libraries and invisibly transform a
> target_link_libraries call.
Do you mean a library or target called LINK_INTERFACE_DEPENDENCIES? Or do
you mean like this:
target_link_libraries(somelib ${ARGS_FROM_SOMEWHERE_ELSE})
where the variable could be a list containing the term
LINK_INTERFACE_DEPENDENCIES?
> What we need is a pair of keywords to switch
> between link+interface and
> link-only dependencies. We allow the keywords only if one of the two is
> the second argument to the command after the target name. For example,
> they can be called "LINK_INTERFACE" for link+interface and "LINK_DEPENDS"
> for link-only:
>
>target_link_libraries(foo LINK_INTERFACE bar LINK_DEPENDS baz)
>if(SOME_FEATURE)
> target_link_libraries(foo LINK_INTERFACE mar LINK_DEPENDS maz)
>endif()
Is this also succeptable to the same
target_link_libraries(somelib ${ARGS_FROM_SOMEWHERE_ELSE})
effect?
>
> Other possible names? Perhaps LINK_PUBLIC and LINK_PRIVATE?
> Perhaps LINK AND LINK_ONLY?
I'll implement it as you suggest with LINK_PUBLIC and LINK_PRIVATE, which
are most clear to me. We can change it once we have an implementation to
talk about.
All the best,
Steve.
--
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
Re: [cmake-developers] Setting the link interface and dependencies in one command
Stephen Kelly wrote: >> Other possible names? Perhaps LINK_PUBLIC and LINK_PRIVATE? >> Perhaps LINK AND LINK_ONLY? > > I'll implement it as you suggest with LINK_PUBLIC and LINK_PRIVATE, which > are most clear to me. We can change it once we have an implementation to > talk about. Well that didn't take long. I pushed a target-link-libraries-interfaces branch to stage. In the branch: target_link_libraries(foo LINK_PRIVATE qtxml LINK_PUBLIC qtcore qtnetwork ) and target_link_libraries(foo LINK_PUBLIC qtcore qtnetwork LINK_PRIVATE qtxml ) are equivalent to: target_link_libraries(foo qtcore qtnetwork qtxml ) target_link_libraries(foo LINK_INTERFACE_LIBRARIES qtcore qtnetwork ) both mean: * foo will link against qtxml, qtcore and qtnetwork * qtcore and qtnetwork will be in the LINK_INTERFACE_LIBRARIES ... target_link_libraries(foo LINK_PUBLIC qtcore qtnetwork ) is equivalent to target_link_libraries(foo qtcore qtnetwork ) * foo will link against qtcore and qtnetwork ... target_link_libraries(foo LINK_PRIVATE qtcore ) is equivalent to: target_link_libraries(foo qtcore ) target_link_libraries(foo TARGET_LINK_LIBRARIES "" ) * foo will link against qtcore * qtcore will not be in the LINK_INTERFACE_LIBRARIES ... target_link_libraries(foo LINK_PRIVATE qtxml ) target_link_libraries(foo LINK_PUBLIC qtcore qtnetwork ) is equivalent to: target_link_libraries(foo qtcore qtxml qtnetwork ) target_link_libraries(foo TARGET_LINK_LIBRARIES qtcore qtnetwork ) * foo will link against qtxml, qtcore and qtnetwork * qtcore and qtnetwork will be in the LINK_INTERFACE_LIBRARIES What do you think? Thanks, Steve. -- 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
Re: [cmake-developers] Setting the link interface and dependencies in one command
Stephen Kelly wrote: > target_link_libraries(foo > LINK_PUBLIC > qtcore > qtnetwork > ) > > is equivalent to > > target_link_libraries(foo > qtcore > qtnetwork > ) > > * foo will link against qtcore and qtnetwork I should have also noted that both qtcore and qtnetwork will also be in the LINK_INTERFACE_LIBRARIES. -- 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
[cmake-developers] try_compile does not work for linker flags?
Hi, The dashboard is heating up with my unit tests again. I have a check for the Wl,--no-undefined flag in the test, and on some platforms the check passes (it seems), but the test fails later. example: http://www.cdash.org/CDash/testDetails.php?test=118193330&build=1601576 Does try_compile not work for linker flags? -- 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
Re: [cmake-developers] try_compile does not work for linker flags?
Brad King wrote: > On 10/7/2011 7:21 AM, Stephen Kelly wrote: >> I have a check for the Wl,--no-undefined flag in the test, and on some >> platforms the check passes (it seems), but the test fails later. > > Many linkers simply warn about an unused flag and ignore it. > It's hard to test for them. Unfortunately I don't have time > now to dig into this to be of further help. > Ok, I've added it to the CheckCXXCompilerFlag unit test in the topic, so hopefully that will show the warnings to check for (if any). -- 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
Re: [cmake-developers] Setting the link interface and dependencies in one command
Brad King wrote: > On 10/6/2011 8:54 PM, Stephen Kelly wrote: >> Well that didn't take long. I pushed a target-link-libraries-interfaces >> branch to stage. > > Good start. Please change the three Doing*Interface modes into an > enumeration so we don't have to worry about keeping three booleans > in a consistent state. Done. > Also, I think the documentation can be > simplified for that signature: > > target_link_libraries( [libs...] > [ [libs...]] ...) > Done. > Of course this will be easier to test once you get your new linking > test working everywhere in the other topic. Yes. Unfortunately I've had to comment out the useful unit tests there (the ones expecting failure) because they don't fail on so many platforms. I'll investigate that particular with a new thread though anyway. Thanks for the review. Steve. -- 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
Re: [cmake-developers] Setting the link interface and dependencies in one command
Bill Hoffman wrote: > On 10/7/2011 11:30 AM, Brad King wrote: >> On 10/7/2011 11:23 AM, Stephen Kelly wrote: >>> Brad King wrote: >>>> Good start. Please change the three Doing*Interface modes into an >>>> enumeration so we don't have to worry about keeping three booleans >>>> in a consistent state. >>> >>> Done. >>> >>>> Also, I think the documentation can be simplified for that signature: >>> >>> Done. >> >> Thanks. >> >> Unfortunately I won't have time to do a serious review of the topics >> >> cmake-link-interface-libraries >> target-link-libraries-interfaces >> >> for a couple of weeks. You're welcome to keep merging to next to see >> results on the dashboard. It won't be in master until after I can take >> time for a thorough review. >> >> Thanks for working on this! >> > Please keep working on fixing the dashboard, there are a few style > errors here: > http://www.cdash.org/CDash/viewBuildError.php?buildid=1601031 > > -Bill > Hmm, hadn't noticed those. The link doesn't show useful information. How do I run those checks locally? -- 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
Re: [cmake-developers] Setting the link interface and dependencies in one command
Eric Noulard wrote:
> 2011/10/7 Stephen Kelly
> :
>> Bill Hoffman wrote:
>
>>>>
>>> Please keep working on fixing the dashboard, there are a few style
>>> errors here:
>>> http://www.cdash.org/CDash/viewBuildError.php?buildid=1601031
>>>
>>> -Bill
>>>
>>
>> Hmm, hadn't noticed those.
>>
>> The link doesn't show useful information. How do I run those checks
>> locally?
>
> You may install kwstyle
> http://public.kitware.com/KWStyle/
> this may already be in you favorite linux distribution repository.
>
> and then configure git local hooks:
> http://www.cmake.org/Wiki/Git/Hooks
> look for:
> git config hooks.KWStyle true
>
> such that kwtyle is run as a pre-commit hook.
>
The instructions don't seem to work:
cmake/.git/hooks{cmake-link-interface-libraries}$ git branch -a | grep hooks
remotes/official/hooks
cmake/.git/hooks{cmake-link-interface-libraries}$ git pull ..
remotes/official/hooks
fatal: /usr/lib/git-core/git-pull cannot be used without a working tree.
cmake/.git/hooks{cmake-link-interface-libraries}$ git pull ../..
remotes/official/hooks
fatal: /usr/lib/git-core/git-pull cannot be used without a working tree.
cmake/.git/hooks{cmake-link-interface-libraries}$ git pull
git://public.kitware.com/cmake.git hooks
fatal: /usr/lib/git-core/git-pull cannot be used without a working tree.
cmake/.git/hooks{cmake-link-interface-libraries}$ git pull
git://cmake.org/cmake.git hooks
fatal: /usr/lib/git-core/git-pull cannot be used without a working tree.
--
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
Re: [cmake-developers] Setting the link interface and dependencies in one command
Stephen Kelly wrote: >> >> such that kwtyle is run as a pre-commit hook. >> > > The instructions don't seem to work: > Oops, they do work. I had missed the part about creating a new repo in my hooks dir. -- 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
Re: [cmake-developers] Setting the link interface and dependencies in one command
Stephen Kelly wrote:
> Stephen Kelly wrote:
>
>>>
>>> such that kwtyle is run as a pre-commit hook.
>>>
>>
>> The instructions don't seem to work:
>>
>
> Oops, they do work. I had missed the part about creating a new repo in my
> hooks dir.
:/
Not finding some conf file:
stephen@hal:~/dev/src/cmake{cmake-link-interface-libraries}$ git commit --am
pre-commit hook failure
---
The file '' does not exist.
Please run
git config hooks.KWStyle.conf path/to/KWStyle.conf.xml
$ sudo updatedb
$ locate KWStyle.conf.xml
$
--
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
Re: [cmake-developers] Setting the link interface and dependencies in one command
Stephen Kelly wrote: > Stephen Kelly wrote: > >> Stephen Kelly wrote: >> >>>> >>>> such that kwtyle is run as a pre-commit hook. >>>> >>> >>> The instructions don't seem to work: >>> >> >> Oops, they do work. I had missed the part about creating a new repo in my >> hooks dir. > > :/ > > Not finding some conf file: I might have found it in the cmake source: cmake/Utilities/KWStyle/CMake.kws.xml.in But it doesn't prevent me from making commits which introduce long lines... -- 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
Re: [cmake-developers] try_compile does not work for linker flags?
Brad King wrote: > On 10/7/2011 7:21 AM, Stephen Kelly wrote: >> I have a check for the Wl,--no-undefined flag in the test, and on some >> platforms the check passes (it seems), but the test fails later. > > Many linkers simply warn about an unused flag and ignore it. > It's hard to test for them. Unfortunately I don't have time > now to dig into this to be of further help. > My test shows that check_cxx_compiler_flag (which creates an executable) doesn't even cause the compiler to issue a warning when the unrecognized compiler flag is used: http://www.cdash.org/CDash/testDetails.php?test=118342963&build=1604891 However, when compiling a shared library it fails directly: http://www.cdash.org/CDash/testDetails.php?test=118193330&build=1601576 Would it break anything if we changed check_cxx_compiler_flag to build a shared library instead of an executable? Maybe that will make the try_compile fail as expected. (I'll try add a test for that now) -- 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
Re: [cmake-developers] Setting the link interface and dependencies in one command
Bill Hoffman wrote: > On 10/7/2011 11:30 AM, Brad King wrote: >> On 10/7/2011 11:23 AM, Stephen Kelly wrote: >>> Brad King wrote: >>>> Good start. Please change the three Doing*Interface modes into an >>>> enumeration so we don't have to worry about keeping three booleans >>>> in a consistent state. >>> >>> Done. >>> >>>> Also, I think the documentation can be simplified for that signature: >>> >>> Done. >> >> Thanks. >> >> Unfortunately I won't have time to do a serious review of the topics >> >> cmake-link-interface-libraries >> target-link-libraries-interfaces >> >> for a couple of weeks. You're welcome to keep merging to next to see >> results on the dashboard. It won't be in master until after I can take >> time for a thorough review. >> >> Thanks for working on this! >> > Please keep working on fixing the dashboard, there are a few style > errors here: > http://www.cdash.org/CDash/viewBuildError.php?buildid=1601031 This seems to be introduced by the ninja branch. I still can't get the style checker working as expected anyway though. -- 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
Re: [cmake-developers] try_compile does not work for linker flags?
Brad King wrote: > On 10/8/2011 7:40 AM, Stephen Kelly wrote: >> Would it break anything if we changed check_cxx_compiler_flag to build a >> shared library instead of an executable? Maybe that will make the >> try_compile fail as expected. (I'll try add a test for that now) > > We cannot make a change like that to such a widely used check. It will > undoubtedly cause subtle behavior changes for other checks. > > You can use the source-tree signature of try_compile to build your own > test project that creates a shared library and tries using that flag. > > BTW, the reason the compiler won't warn about -Wl,--no-undefined is > because "-Wl," is the part parsed by the compiler. It then passes the > --no-undefined option to the linker, and the linker is not warning. Yes, I realised all this yesterday too and wrote a new macro check_cxx_linker_flags. It required changing try_compile to not use add_executable, but optionally to create a shared library. It is staged as check-cxx-linker-flags, and seems to work on linux for me. (I haven't tried on windows yet) -- 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
[cmake-developers] Apple tests for target_link_libraries failing
Hi, I'm trying to find out why the target_link_libraries unit tests are failing on some platforms (but not mine...). I'm enabling one platform at a time. I enabled the failing tests for APPLE, so if you want to try it out, you need to comment out the if(APPLE). http://www.cdash.org/CDash/testDetails.php?test=118643411&build=1613858 The executable in both failing tests is linking to libraries A, B and C, so the executable builds successfully therefore failing the test. On my system it correctly links the application to libraries A and C only in one of the tests, therefore symbols from library B are not found, and the build fails as expected. 153: 153: Linking CXX executable exec 153: 153: /home/stephen/dev/build/qt48/cmake/bin/cmake -E cmake_link_script 153: CMakeFiles/exec.dir/link.txt --verbose=1 153: 153: /usr/lib/icecc/bin/c++ CMakeFiles/exec.dir/main.cpp.o -o exec - rdynamic 153: /home/stephen/dev/build/qt48/cmake/Tests/CMakeCommands/target_link_libraries/libs_build_True_True/liblibC.so 153: /home/stephen/dev/build/qt48/cmake/Tests/CMakeCommands/target_link_libraries/libs_build_True_True/liblibA.so 153: -Wl,- rpath,/home/stephen/dev/build/qt48/cmake/Tests/CMakeCommands/target_link_libraries/libs_build_True_True 153: -Wl,-rpath- link,/home/stephen/dev/build/qt48/cmake/Tests/CMakeCommands/target_link_libraries/libs_build_True_True 153: 153: 153: CMakeFiles/exec.dir/main.cpp.o:main.cpp:function main: error: undefined 153: reference to 'classB::classB()' 153: Can someone with an apple find out what is causing the B library to appear in the link line on APPLE, but not on my system? I can't fix the test because I have no apple. Thanks, Steve. -- 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
Re: [cmake-developers] Apple tests for target_link_libraries failing
Bill Hoffman wrote:
> On 10/11/2011 2:33 AM, Stephen Kelly wrote:
>>
>> Hi,
>>
>> I'm trying to find out why the target_link_libraries unit tests are
>> failing on some platforms (but not mine...). I'm enabling one platform at
>> a time. I enabled the failing tests for APPLE, so if you want to try it
>> out, you need to comment out the if(APPLE).
>>
>
> So, the test is still failing on the dashboard now right? I see it
> failed last night on all the macs, and on the continuous this morning.
> So, what do we need to comment out? Are you going to at least
> temporarily fix the dashboard test failures today? Did you mean to say
> if(NOT APPLE) maybe?
Nope, a few days ago it failed on more than just macs, it also failed on
some windows and BSD, but I don't know why. Rather than make the whole
dashboard light up, I only enabled the tests for APPLE first. I guess that
once we find out why that does not work as expected, the fix will fix all
other platforms too.
>
>
> The test output from these tests are very hard for me to parse:
>
> http://www.cdash.org/CDash/testDetails.php?test=118663911&build=1614189
>
> Something is failing but I have no idea what. Perhaps you could
> annotate the tests a bit more so that it prints out a test name or
> something.
>
> "Testing link with CLEAR_LINK_INTERFACE_LIBRARIES=TRUE,
> SPECIFY_LINK_INTERFACE_LIBRARIES = TRUE
> test # 2.
>
> Or maybe even put a name into the expect_fail calls so that when it
> fails you can easily go back to the line in the CMakeLists.txt where the
> expect_fail is called.Maybe the test should print out the
> CMakeLists.txt file that was generated for it?
>
>
I can look into doing these things. Seems like a good idea.
>
>
> So, in this case:
> http://www.cdash.org/CDash/testDetails.php?test=118663911&build=1614189
>
> What is it you can not see in your output?
>
> It looks to me that for each of them it is linking everything:
>
> /usr/bin/g++-4.2 -Wall -Wextra -Wformat=2 -Wno-format-nonliteral
> -Wunused
>-Wpointer-arith -Winvalid-pch -Wcast-align -Wdisabled-optimization
>-Wnewline-eof -fdiagnostics-show-option -Woverloaded-virtual -Wshadow
>-Wwrite-strings -g -fstack-protector-all -D_FORTIFY_SOURCE=2 -arch ppc
>-isysroot /Developer/SDKs/MacOSX10.5.sdk -Wl,-search_paths_first
>-Wl,-headerpad_max_install_names CMakeFiles/exec.dir/main.cpp.o -o exec
>
> /Users/builder/kitware/CMake-gcc-dbg-
ppc/Tests/CMakeCommands/target_link_libraries/libs_build_True_True/liblibC.dylib
>
> /Users/builder/kitware/CMake-gcc-dbg-
ppc/Tests/CMakeCommands/target_link_libraries/libs_build_True_True/liblibA.dylib
>
> /Users/builder/kitware/CMake-gcc-dbg-
ppc/Tests/CMakeCommands/target_link_libraries/libs_build_True_True/liblibB.dylib
>
> If that is true, then the issue must be in the generator some how...
>
It indeed looks like it is linking against everything, but it should not be.
> However, I am not really sure if I am looking at the right link line
>
I think you are.
>
> Bottom line, can you make the test pass again, and what experiment do
> you want someone on a mac to do for you?
>
I have attached a tarball. For me it fails when linking the executable.
CMakeFiles/exec.dir/main.cpp.o:main.cpp:function main: error: undefined
reference to 'classB::classB()'
This is the expected result because I have used
set(CMAKE_LINK_INTERFACE_LIBRARIES "")
It should work on all platforms as far as I know. Commenting out the test
would make it look like the feature works, though it does not work on APPLE
and maybe others.
If that builds on APPLE for you, please check why the line in cmTarget.cxx:
this->SetPropertyDefault("LINK_INTERFACE_LIBRARIES", 0);
introduced in commit ac4dd41bcc3818f010fc19e28b2e76e2407d2a09 is not having
the desired effect on APPLE.
Thanks,
Steve.
build_should_fail.tar.gz
Description: application/compressed-tar
--
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
Re: [cmake-developers] Apple tests for target_link_libraries failing
Bill Hoffman wrote:
> So, basically we this:
>
>
> set(CMAKE_LINK_INTERFACE_LIBRARIES "")
>
> add_library(libA SHARED classA.cpp)
> add_library(libB SHARED classB.cpp)
> add_library(libC SHARED classC.cpp)
>
> generate_export_header(libA)
> generate_export_header(libB)
> generate_export_header(libC)
>
> target_link_libraries(libB libA)
> target_link_libraries(libC libA libB)
>
> add_executable(exec
>"main.cpp"
> )
> target_link_libraries(exec libC )
>
>
> So, setting CMAKE_LINK_INTERFACE_LIBRARIES to "" is supposed to make the
> transitive linking of A and B not happen when linking C. I tried adding
> some print stuff in the code. But, I am not sure where to look.
>
> I added the following:
>
> void cmTarget::SetPropertyDefault(const char* property,
> const char* default_value)
> {
> + bool debug = false;
> + if(strcmp("LINK_INTERFACE_LIBRARIES", property) == 0)
> +debug = true;
> + if(debug) std::cerr << this->GetName() << "\n";
> // Compute the name of the variable holding the default value.
> std::string var = "CMAKE_";
> var += property;
> -
> + if(debug) std::cerr << var << "\n";
> if(const char* value = this->Makefile->GetDefinition(var.c_str()))
> {
> +if(debug) std::cerr << "found it " << value << "\n";
> this->SetProperty(property, value);
> }
> else if(default_value)
> {
> +if(debug) std::cerr << "not found " << default_value << "\n";
> this->SetProperty(property, default_value);
> }
> }
> diff --git a/Source/cmTargetLinkLibrariesCommand.cxx b/Source/cmTargetLin
> kLibrariesCommand.cxx
> index 805959d..d2be3fa 100644
> --- a/Source/cmTargetLinkLibrariesCommand.cxx
> +++ b/Source/cmTargetLinkLibrariesCommand.cxx
> @@ -219,6 +219,7 @@ cmTargetLinkLibrariesCommand::HandleLibrary(const cha
> r* lib,
> // Handle normal case first.
> if(!this->DoingInterface)
> {
> +std::cerr << this->Target->GetName() << " Not doing interface" << "\
> n";
> this->Makefile
>
>
> I ended up with this:
>
> libA
> CMAKE_LINK_INTERFACE_LIBRARIES
> found it
> libB
> CMAKE_LINK_INTERFACE_LIBRARIES
> found it
> libC
> CMAKE_LINK_INTERFACE_LIBRARIES
> found it
>
>
> libB Not doing interface
> libC Not doing interface
> libC Not doing interface
>
>
> Do you have other prints that I should add? How is this supposed to work?
>
> -Bill
>
How exactly it works I am not entirely certain. I followed the suggestion in
this thread:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/1865/focus=1868
and it just worked for me.
I assume the contents of LINK_INTERFACE_LIBRARIES gets read somewhere else
to create the actual link line. each of libA libB and libC do not get added
to the link_interfaces, and using set(CMAKE_LINK_INTERFACE_LIBRARIES "")
should be the same as using
target_link_libraries(libA LINK_INTERFACE_LIBRARIES "")
for each library.
It works for me, but I don't know why it doesn't work for you. Maybe Brad
can have some insight?
Thanks,
Steve.
--
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
Re: [cmake-developers] Apple tests for target_link_libraries failing
Brad King wrote: > On 10/12/2011 2:22 AM, Stephen Kelly wrote: >> using set(CMAKE_LINK_INTERFACE_LIBRARIES "") should be the same as using >> >> target_link_libraries(libA LINK_INTERFACE_LIBRARIES "") >> >> for each library. > > It is. The example under discussion has the same behavior even if you > explicitly set it on each target. > The behavior we are seeing in the test on Apple can be changed to the > expected behavior by adding > > SET(CMAKE_LINK_DEPENDENT_LIBRARY_FILES 0) > > to the CMakeLists.txt file. However, I don't remember the details of why > I had to add that to Darwin.cmake in the first place. Hopefully there is > a better fix for the original problem. Ok, knowing why it fails on APPLE is good enough for me for now. The tests can be enabled on APPLE again later, I've flipped the if condition so we can see why it fails on some non-APPLE platforms too. I already grepped for CMAKE_LINK_DEPENDENT_LIBRARY_FILES and it seems to not appear anywhere else but Darwin.cmake. I remember the tests failing on freebsd and some windows too, so if you have any idea why that might be, I'd be interested to know. Thanks, Steve. -- 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
Re: [cmake-developers] Apple tests for target_link_libraries failing
On 10/12/2011 06:37 PM, Richard Wackerbarth wrote: Given the question about "other platforms", I did an update to next on my newest FreeBSD build machine. New revision of repository is: f48a0be07ebcdbe5d6c6a10d34e70cce164d9a9b Bad news: Start 147: CMakeCommands.target_link_libraries 19/206 Test #147: CMakeCommands.target_link_libraries .***Failed 16.00 sec The complete test will appear on the dashboard when the other half of the tests complete. (Perhaps 5 minutes) Richard Thanks for that. Any information you can give about why it fails would be useful. For easyness of testing, you can ignore the unit test for now and try out the tarball I posted earlier: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/1985/focus=1988 Does it fail to build as expected? Please also try the attached tarball. It is also expected to fail to build. Thanks, Steve. build_should_also_fail.tar.gz Description: application/gzip -- 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
Re: [cmake-developers] Apple tests for target_link_libraries failing
Stephen Kelly wrote: > The tests can be enabled on APPLE again later, I've flipped the if > condition so we can see why it fails on some non-APPLE platforms too. > This is even more interesting now. http://www.cdash.org/CDash/testDetails.php?test=118872016&build=1620094 On gentoo, the build of the exec executable succeeds, even though it only links to libC, and that only links to libA, even though it uses classB from libB (which is not linked to). Can someone with access to that box check if the result actually runs? For easyness of testing you can use either of the two tarballs I send to this thread already. Thanks, Steve. -- 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
Re: [cmake-developers] Apple tests for target_link_libraries failing
Rolf Eike Beer wrote: >>> Stephen Kelly wrote: >>> >>>> The tests can be enabled on APPLE again later, I've flipped the if >>>> condition so we can see why it fails on some non-APPLE platforms too. >>>> >>> >>> This is even more interesting now. >>> >>> http://www.cdash.org/CDash/testDetails.php?test=118872016&build=1620094 >>> >>> On gentoo, the build of the exec executable succeeds, even though it >>> only >>> links to libC, and that only links to libA, even though it uses classB >>> from >>> libB (which is not linked to). >> >> libB is in the needed section (see below). The only special thing that I >> can think of is the -Wl,--unique=.text.* flag I put into C_FLAGS, as >> CMake itself would otherwise not link because of a binutils breakage. No >> idea if that is related. > > Ok, it is not related. I rebuild only that testcase without that flag and > it did not change anything. > > But I noticed another thing. In the dashboard above 2 tests are failing: > 19 and 20. I think the test #20 is actually wrong, as it seems to depend > on linker flags that may just be activated by default on the machines you > use. If I manually specify > LDFLAGS=-Wl,--no-copy-dt-needed-entries,--as-needed when I call CMake for > the first time #20 succeeds for me. So it looks like this is just > "accidentially" working, but in fact you may need to pass these flags > yourself to make sure they are always there. > You mean everyone needs to specify them if they use LINK_INTERFACE_LIBRARIES "" anywhere, right? If that's true then setting that variable to empty should maybe add those flags automatically. I'm not certain that's correct though. Those flags don't seem to be used when I build. I also don't know what those flags do. Linking CXX executable exec /home/stephen/dev/qt48/kde/bin/cmake -E cmake_link_script CMakeFiles/exec.dir/link.txt --verbose=1 /usr/lib/icecc/bin/c++ CMakeFiles/exec.dir/main.cpp.o -o exec - rdynamic lib/liblibC.so -Wl,-rpath,/home/stephen/cmaketest/test19/build/lib -Wl,-rpath-link,/home/stephen/cmaketest/test19/build/lib CMakeFiles/exec.dir/main.cpp.o:main.cpp:function main: error: undefined reference to 'classB::classB()' collect2: ld returned 1 exit status make[2]: *** [exec] Error 1 make[2]: Leaving directory `/home/stephen/cmaketest/test19/build' Thanks, Steve. -- 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
Re: [cmake-developers] Apple tests for target_link_libraries failing
Rolf Eike Beer wrote: >> I'm not certain that's correct though. Those flags don't seem to be used >> when I build. I also don't know what those flags do. >> >> Linking CXX executable exec >> /home/stephen/dev/qt48/kde/bin/cmake -E cmake_link_script >> CMakeFiles/exec.dir/link.txt --verbose=1 >> /usr/lib/icecc/bin/c++ CMakeFiles/exec.dir/main.cpp.o -o exec - >> rdynamic lib/liblibC.so >> -Wl,-rpath,/home/stephen/cmaketest/test19/build/lib >> -Wl,-rpath-link,/home/stephen/cmaketest/test19/build/lib >> CMakeFiles/exec.dir/main.cpp.o:main.cpp:function main: error: undefined >> reference to 'classB::classB()' >> collect2: ld returned 1 exit status >> make[2]: *** [exec] Error 1 >> make[2]: Leaving directory `/home/stephen/cmaketest/test19/build' > > Maybe this is just the default setting for your binutils. Try > LDFLAGS=-Wl,--copy-dt-needed-entries,-no-as-needed and see what happens. I > bet this will change the behavior on your system. > ld now gives a new error: /usr/bin/ld: error: --copy-dt-needed-entries is not supported but is required for liblibA.so in lib/liblibC.so Here's a more complete fragment: Linking CXX executable exec /home/stephen/dev/qt48/kde/bin/cmake -E cmake_link_script CMakeFiles/exec.dir/link.txt --verbose=1 /usr/lib/icecc/bin/c++ -Wl,--copy-dt-needed-entries,-no-as-needed CMakeFiles/exec.dir/main.cpp.o -o exec -rdynamic lib/liblibC.so -Wl,- rpath,/home/stephen/cmaketest/test19/build/lib -Wl,-rpath- link,/home/stephen/cmaketest/test19/build/lib /usr/bin/ld: error: --copy-dt-needed-entries is not supported but is required for liblibA.so in lib/liblibC.so CMakeFiles/exec.dir/main.cpp.o:main.cpp:function main: error: undefined reference to 'classB::classB()' collect2: ld returned 1 exit status I also ran ctest -V -R target_link_librares with those flags and many more tests failed. I have no idea what those flags do, so I don't know if that new error is a lead. Thanks, Steve. -- 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
Re: [cmake-developers] Apple tests for target_link_libraries failing
akeFiles/libC.dir/depend > cd /home/rkw/test19-build && /usr/local/bin/cmake -E cmake_depends "Unix > Makefiles" /home/rkw/test19 /home/rkw/test19/lib /home/rkw/test19-build > /home/rkw/test19-build/lib > /home/rkw/test19-build/lib/CMakeFiles/libC.dir/DependInfo.cmake --color= > Scanning dependencies of target libC > make -f lib/CMakeFiles/libC.dir/build.make lib/CMakeFiles/libC.dir/build > /usr/local/bin/cmake -E cmake_progress_report > /home/rkw/test19-build/CMakeFiles 4 > [ 75%] Building CXX object lib/CMakeFiles/libC.dir/classC.cpp.o > cd /home/rkw/test19-build/lib && /usr/bin/c++  -DlibC_EXPORTS -fPIC > -I/home/rkw/test19-build/lib -I/home/rkw/test19/lib -o > CMakeFiles/libC.dir/classC.cpp.o -c /home/rkw/test19/lib/classC.cpp > Linking CXX shared library liblibC.so > cd /home/rkw/test19-build/lib && /usr/local/bin/cmake -E cmake_link_script > CMakeFiles/libC.dir/link.txt --verbose=1 > /usr/bin/c++  -fPIC   -shared -Wl,-soname,liblibC.so -o liblibC.so > CMakeFiles/libC.dir/classC.cpp.o liblibA.so liblibB.so liblibA.so > -Wl,-rpath,/home/rkw/test19-build/lib > /usr/local/bin/cmake -E cmake_progress_report > /home/rkw/test19-build/CMakeFiles  4 > [ 75%] Built target libC > make -f CMakeFiles/exec.dir/build.make CMakeFiles/exec.dir/depend > cd /home/rkw/test19-build && /usr/local/bin/cmake -E cmake_depends "Unix > Makefiles" /home/rkw/test19 /home/rkw/test19 /home/rkw/test19-build > /home/rkw/test19-build > /home/rkw/test19-build/CMakeFiles/exec.dir/DependInfo.cmake --color= > Scanning dependencies of target exec > make -f CMakeFiles/exec.dir/build.make CMakeFiles/exec.dir/build > /usr/local/bin/cmake -E cmake_progress_report > /home/rkw/test19-build/CMakeFiles 1 > [100%] Building CXX object CMakeFiles/exec.dir/main.cpp.o > /usr/bin/c++   -I/home/rkw/test19-build -I/home/rkw/test19 > -I/home/rkw/test19/lib -I/home/rkw/test19-build/lib -o > CMakeFiles/exec.dir/main.cpp.o -c /home/rkw/test19/main.cpp > Linking CXX executable exec > /usr/local/bin/cmake -E cmake_link_script CMakeFiles/exec.dir/link.txt > --verbose=1 > /usr/bin/c++    CMakeFiles/exec.dir/main.cpp.o  -o exec  lib/liblibC.so > -Wl,-rpath,/home/rkw/test19-build/lib > -Wl,-rpath-link,/home/rkw/test19-build/lib > /usr/local/bin/cmake -E cmake_progress_report > /home/rkw/test19-build/CMakeFiles  1 > [100%] Built target exec > /usr/local/bin/cmake -E cmake_progress_start > /home/rkw/test19-build/CMakeFiles 0 > [rkw@Chameleon-12 ~/test19-build]$ > > > On Oct 13, 2011, at 1:43 AM, Stephen Kelly wrote: > >> On 10/12/2011 08:18 PM, Richard Wackerbarth wrote: >>> Stephen, >>> >>> I'm not sure what you were expecting. >>> The testing starts was with the version of test19 from the email thread. >>> The second run is from the file that you attached. >>> >>> Let me know what else you would find useful. >> >> Hi Richard, >> >> You didn't actually build the code. You only ran cmake. You need to run make >> to attempt to build it (which should fail). >> >> Please send the result to the mailing list. >> >> Thanks, >> >> Steve. >> >>> Richard >>> >>> [rkw@Chameleon-12 ~/test19-build]$ >>> ~/Chameleon-12/CMake/Experimental/CMake-build/bin/cmake ../test19 >>> -- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY >>> -- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY - Success >>> -- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY >>> -- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY - Success >>> -- Performing Test COMPILER_HAS_DEPRECATED_ATTR >>> -- Performing Test COMPILER_HAS_DEPRECATED_ATTR - Success >>> -- Configuring done >>> -- Generating done >>> -- Build files have been written to: /home/rkw/test19-build >>> [rkw@Chameleon-12 ~/test19-build]$ ls >>> CMakeCache.txt        CMakeFiles        Makefile        >>>  cmake_install.cmake   lib >>> [rkw@Chameleon-12 ~/test19-build]$ cd >>> [rkw@Chameleon-12 ~]$ ls >>> test19        build_should_also_fail.tar.gz  test19-build >>> [rkw@Chameleon-12 ~]$ mv test19 test19-save >>> [rkw@Chameleon-12 ~]$ tar -xzf build_should_also_fail.tar.gz >>> [rkw@Chameleon-12 ~]$ diff -r test19 test19-save/ >>> diff -r test19/lib/CMakeLists.txt test19-save/lib/CMakeLists.txt >>> 13,14c13 >>> <  # This is commented out: >>> <  # set(CMAKE_LINK_INTERFACE_LIBRARIES "") >>> --- >>>> set(CMAKE_LINK_INTERFACE_LIBRARIES "") >>> 26,30d24 &
Re: [cmake-developers] Apple tests for target_link_libraries failing
Rolf Eike Beer wrote: >> Rolf Eike Beer wrote: >> I'm not certain that's correct though. Those flags don't seem to be used when I build. I also don't know what those flags do. Linking CXX executable exec /home/stephen/dev/qt48/kde/bin/cmake -E cmake_link_script CMakeFiles/exec.dir/link.txt --verbose=1 /usr/lib/icecc/bin/c++ CMakeFiles/exec.dir/main.cpp.o -o exec - rdynamic lib/liblibC.so -Wl,-rpath,/home/stephen/cmaketest/test19/build/lib -Wl,-rpath-link,/home/stephen/cmaketest/test19/build/lib CMakeFiles/exec.dir/main.cpp.o:main.cpp:function main: error: undefined reference to 'classB::classB()' collect2: ld returned 1 exit status make[2]: *** [exec] Error 1 make[2]: Leaving directory `/home/stephen/cmaketest/test19/build' >>> >>> Maybe this is just the default setting for your binutils. Try >>> LDFLAGS=-Wl,--copy-dt-needed-entries,-no-as-needed and see what happens. >>> I >>> bet this will change the behavior on your system. >> >> ld now gives a new error: >> >> /usr/bin/ld: error: --copy-dt-needed-entries is not supported but is >> required for liblibA.so in lib/liblibC.so >> >> Here's a more complete fragment: >> >> Linking CXX executable exec >> /home/stephen/dev/qt48/kde/bin/cmake -E cmake_link_script >> CMakeFiles/exec.dir/link.txt --verbose=1 >> /usr/lib/icecc/bin/c++ -Wl,--copy-dt-needed-entries,-no-as-needed >> CMakeFiles/exec.dir/main.cpp.o -o exec -rdynamic lib/liblibC.so -Wl,- >> rpath,/home/stephen/cmaketest/test19/build/lib -Wl,-rpath- >> link,/home/stephen/cmaketest/test19/build/lib >> /usr/bin/ld: error: --copy-dt-needed-entries is not supported but is >> required for liblibA.so in lib/liblibC.so >> CMakeFiles/exec.dir/main.cpp.o:main.cpp:function main: error: undefined >> reference to 'classB::classB()' >> collect2: ld returned 1 exit status >> >> I also ran ctest -V -R target_link_librares with those flags and many >> more tests failed. >> >> I have no idea what those flags do, so I don't know if that new error is >> a lead. > > This may be new in my binutils version. Can you just try > LDFLAGS=-Wl,-no-as-needed? > > Eike Back to what it was before now: Linking CXX executable exec /home/stephen/dev/qt48/kde/bin/cmake -E cmake_link_script CMakeFiles/exec.dir/link.txt --verbose=1 /usr/lib/icecc/bin/c++ -Wl,-no-as-needed CMakeFiles/exec.dir/main.cpp.o -o exec -rdynamic lib/liblibC.so -Wl,- rpath,/home/stephen/cmaketest/test19/build/lib -Wl,-rpath- link,/home/stephen/cmaketest/test19/build/lib CMakeFiles/exec.dir/main.cpp.o:main.cpp:function main: error: undefined reference to 'classB::classB()' I also tried running ctest -V -R target_link_libraries again, and it succeeded in all tests. Thanks, Steve. -- 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
Re: [cmake-developers] Apple tests for target_link_libraries failing
Stephen Kelly wrote: > > Ok, knowing why it fails on APPLE is good enough for me for now. > > The tests can be enabled on APPLE again later, I've flipped the if > condition so we can see why it fails on some non-APPLE platforms too. > I was given access to a freebsd box to see why the build succeeds there. The link line looks like this: ~/test19-build]$ vi CMakeFiles/exec.dir/link.txt /usr/bin/c++ -Wl,-no-as-needed CMakeFiles/exec.dir/main.cpp.o -o exec lib/liblibC.so -Wl,-rpath,/home/steve/test19-build/lib -Wl,-rp ath-link,/home/steve/test19-build/lib and then ldd reports that it is also linked against liblibB.so. ~/test19-build]$ ldd exec exec: liblibC.so => /home/steve/test19-build/lib/liblibC.so (0x800849000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x800a4a000) libm.so.5 => /lib/libm.so.5 (0x800d55000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x800f76000) libc.so.7 => /lib/libc.so.7 (0x801183000) liblibB.so => /home/steve/test19-build/lib/liblibB.so (0x8014cb000) liblibA.so => /home/steve/test19-build/lib/liblibA.so (0x8016cc000) I can't explain why. I also tried with export LDFLAGS=-Wl,-no-as-needed with the same result. For the moment I think I'll give up on testing the actual result of the build, but I'll just compare the result with the 'control point' of building with all targets with their LINK_INTERFACE_LIBRARIES set to empty. That will be a good enough unit test for the CMAKE_LINK_INTERFACE_LIBRARIES and makes fixing all of the issues with it not my responsibility :). It also means that I don't become an expert in linker options :). Should be done tomorrow. Thanks, Steve. -- 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
Re: [cmake-developers] Apple tests for target_link_libraries failing
Stephen Kelly wrote: > > Ok, knowing why it fails on APPLE is good enough for me for now. > > The tests can be enabled on APPLE again later, I've flipped the if > condition so we can see why it fails on some non-APPLE platforms too. > I was given access to a freebsd box to see why the build succeeds there. The link line looks like this: ~/test19-build]$ vi CMakeFiles/exec.dir/link.txt /usr/bin/c++ -Wl,-no-as-needed CMakeFiles/exec.dir/main.cpp.o -o exec lib/liblibC.so -Wl,-rpath,/home/steve/test19-build/lib -Wl,-rp ath-link,/home/steve/test19-build/lib and then ldd reports that it is also linked against liblibB.so. ~/test19-build]$ ldd exec exec: liblibC.so => /home/steve/test19-build/lib/liblibC.so (0x800849000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x800a4a000) libm.so.5 => /lib/libm.so.5 (0x800d55000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x800f76000) libc.so.7 => /lib/libc.so.7 (0x801183000) liblibB.so => /home/steve/test19-build/lib/liblibB.so (0x8014cb000) liblibA.so => /home/steve/test19-build/lib/liblibA.so (0x8016cc000) Nope, you got that wrong. What that means is that liblibB.so will get loaded to satisfy some dynamic library dependencies when exec is called. It does not mean that exec got linked against liblibB, but that exec or any of it's dependencies was linked against liblibB. So you will likely see the very same result on any exec that was successfully linked. What you are looking for is objdump or readelf, they will tell you what is actually in exec and not in it's dependencies. Eike signature.asc Description: This is a digitally signed message part. -- 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
[cmake-developers] Keeping unit tests useful and splitting feature support from platform support
Hi, I've been pushing some changes to the unit tests on the cmake-link-interface-libraries branch which is merged into next. Where the unit tests that I wrote were failing before in some cases, my changes make the dashboard go green again, but they don't actually make CMake any better. That branch expects that the LINK_INTERFACE_LIBRARIES feature of CMake actually has an effect. That is not the case on some platforms for various reasons. Now I test that the feature 'works', and then run the actual unit tests for my feature if it does. Now, if something breaks in the future causing my feature not to work anymore, the unit tests might not start to fail (they might not even be run anymore), so I would get no indication that something is wrong. That is what unit tests are supposed to provide for me. I've hit issues like this now on the generate_export_header work, and on this LINK_INTERFACE_LIBRARIES work. In the case of the generate_export_header work it is at least possible to run a try_compile test, and the result (and availability of the feature) is reported in the output of an invocation of cmake. In the case of LINK_INTERFACE_LIBRARIES, it might have no effect, and because it is implemented in C++ code, not a CMake module, I can't report its availability in the output of an invocation of cmake. Having so many old platforms and compilers on the dashboard going red with failure when I add unit tests is also quite demotivating for me, because anything on the dashboard going red is 'must fix' by definition. In some cases, having more platforms there has shown a 'real' problem in the code, but for sure not all. What I'd like to see is a distinction of feature support from platform support. In my case, I care about writing some features in cmake, but I don't care about watcom, GCC 3.3.1 etc. What I'd like to do is make sure my feature works on some 'reference platforms', which could be anything 'non- ancient', and fixing it on the ancient ones would become not-my-problem. The policy would then be that if unit tests that I write fail on other 'non- reference platforms', it wouldn't be my responsibility to fix it, and it wouldn't prevent the feature being merged to master, but it would fall to whoever cares about watcom, gcc 3.3.1 etc. So, I think I'm talking about two separate issues. One is whether failures on platforms I don't care about are my repsonsibility, and the other is ensuring that unit tests fail when something breaks. Rather than me running a try_compile to see if LINK_INTERFACE_LIBRARIES works, I would test for if (CMAKE_REFERENCE_PLATFORM). A reference platform is defined to be a platform on which the features of cmake are available. Then if LINK_INTERFACE_LIBRARIES fails on some reference platform, I would know about it. There would need to be some easy way of excluding platforms from being a reference platforms. Currently that is difficult because you have to look at failures and passes on the dashboard, figure out what the difference between them is, and find a way to exclude one without accidentally excluding the other. I don't know if there is a workable solution to this, so I'm wondering what others think: Is it workable to have a set of 'reference platforms' (which may or may not be communicated, or may just apply to the cmake cdash instance) on which unit tests can be expected to pass, and other platforms on which responsibility rests with the people who care about the platform? Thanks, Steve. -- 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
Re: [cmake-developers] Keeping unit tests useful and splitting feature support from platform support
On 10/16/2011 02:56 PM, Richard Wackerbarth wrote: On Oct 16, 2011, at 6:54 AM, Stephen Kelly wrote: Having so many old platforms and compilers on the dashboard going red with failure So, I think I'm talking about two separate issues. One is whether failures on platforms I don't care about are my responsibility, and the other is ensuring that unit tests fail when something breaks. Steve, This is the "backward compatibility" issue that plagues all projects. Since CMake is a development tool, you have to consider its audience. Suppose you generate some "wiz-bang" new feature that only works when the generator is for the clang compiler and using Xcode. You decide "It's too much trouble to support Visual Studio" or the gcc 4.0 compiler." Now as a package developer, I have to choose from the following options: 1) Drop my support for platforms that your feature doesn't support, 2) Avoid using the "wiz-bang" feature, or 3) Avoid CMake entirely The problem is that I was happy with the feature set of CMake 2.4 and don't "need" "wiz-bang". A POLICY can provide notice that "the wiz-bang feature is not supported on this platform". But CMake still has to support "the old way". Adding features that are not supported on ALL supported platforms reduces the utility of CMake as a viable cross-platform tool. Adding unsupported features really confuses the definition of CMake. At some point, we should "bite the bullet", freeze the feature set of CMake and start a new CMake2 project. In doing so, we can drop all support for certain platforms and the need to support backward compatibility. But, within each version of the product, all of its features need to work on all platforms supported by the product. I think that it is YOUR responsibility to make any new feature work on all supported platforms. If you cannot support some particular platform, you can petition the CMake community to drop support for certain platforms. But it should not be your unilateral choice to do so. Richard Hi Richard, I'm trying to find a solution to an issue I perceive about unit tests not counting for much if we only run them when they are testably already working. There may be other ways to make that work, but your response indicates that you strongly think what I proposed is the wrong approach. You might be right, I don't know. I came up with this proposal after looking at the Qt approach to platform support -- They define reference platforms, and if others want to make Qt work on WinCE for example, they can do that work and be the experts in it. I don't mean to say that what Qt does will automatically work for CMake (unlikely in fact). I'm trying to explore options. All the best, Steve. PS, please subscribe to the cmake-developers mailing list. I think your mails are being held in moderation. At least they don't appear on gmane: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/2023 (also your previous mails never made it to the list) -- 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
Re: [cmake-developers] Keeping unit tests useful and splitting feature support from platform support
Rolf Eike Beer wrote: > Stephen Kelly wrote: > >> What I'd like to see is a distinction of feature support from platform >> support. In my case, I care about writing some features in cmake, but I >> don't care about watcom, GCC 3.3.1 etc. What I'd like to do is make sure >> my feature works on some 'reference platforms', which could be anything >> 'non- ancient', and fixing it on the ancient ones would become >> not-my-problem. > > I find this all natural (but it's not my decision). I'm not sure what this statement means. > On the other hand we > have some other features (like e.g. the source_group stuff) that depend on > generators and compilers. > > One thing that I would only call "fallout" of such a thing, but that I > would love to see is a way to get the compiler version for the currently > active (C, C++, Fortran, ASM) compilers. That would probably help with > your use case, too, when you can determine the version and show a sensible > error message if the compiler version is too old. > > Eike Yes, while a way to get the cross-compiler compiler version would be a step in the right direction, it might not help in the case of features written in C++, as you have no opportunity to run platform checks to enable features at all. Steve. -- 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
[cmake-developers] Merging cmake-link-interface-libraries into master?
Hi, I saw that the weekly merge of branches into master happened yesterday, but the cmake-link-interface-libraries branch didn't make the cut. So I'd like to know: 1) What made it not get merged? 2) What has to change for it to get merged in? All the best, Steve. -- 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
Re: [cmake-developers] Merging cmake-link-interface-libraries into master?
Brad King wrote: > On 10/19/2011 6:04 AM, Stephen Kelly wrote: >> I saw that the weekly merge of branches into master happened yesterday, >> but the cmake-link-interface-libraries branch didn't make the cut. > > Thanks for your work on this. > >> So I'd like to know: >> >> 1) What made it not get merged? >> >> 2) What has to change for it to get merged in? > > I said last week I wouldn't be able to review it thoroughly for at > least two weeks. That means not until next week at the earliest. Ah I see. I forgot about that and when it was you said that. Not a major rush anyway. I'm still trying to get used to the cmake development and release model. Sorry for the noise, Steve. -- 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
Re: [cmake-developers] Merging cmake-link-interface-libraries into master?
Brad King wrote: > On 10/19/2011 11:14 AM, Stephen Kelly wrote: >>> On 10/19/2011 6:04 AM, Stephen Kelly wrote: >>>> I saw that the weekly merge of branches into master happened yesterday, >>>> but the cmake-link-interface-libraries branch didn't make the cut. > [snip] >> Not a major rush anyway. I'm still trying to get used to the cmake >> development and release model. > > The work on the target_link_libraries test is much more comprehensive than > just this one CMAKE_LINK_INTERFACE_LIBRARIES feature, and as you > discovered > much harder to complete. I published two branches here: > >https://github.com/bradking/CMake/branches > > The "cmake-link-interface-libraries" branch is a rewritten version of your > branch that takes just the part for the new feature. The second > "test-target_link_libraries" branch is a rewritten version of the rest > of your branch that adds the test, and is based on the first branch. The > end of the second branch has an identical Git tree object as the current > stage/cmake-link-interface-libraries branch (at d951f012). > > I'd like to replace your branch on the stage with these two so we can > merge the feature and leave the comprehensive test as a work in progress > for now. Is that okay with you? > Yes, that's ok with me. I guess I can continue to create separate branches for tests and features in the future too. I've just merged the target-link-libraries-interfaces branch into next, so I can maybe add tests for that feature whenever the test-target_link_libraries is more ready. What work needs to be done for test-target_link_libraries to leave the wip state? What does CMake think about rebasing? I much prefer to squash a branch like test-target_link_libraries into fewer commits so that eg adding newlines and changing tests to examine dashboard changes are not separate commits. I don't think those commits add value, but only noise. Can I squash them in the stage clone if you push those branches there? Do I have karma to push -f to stage? Thanks, Steve. -- 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
Re: [cmake-developers] Merging cmake-link-interface-libraries into master?
Brad King wrote: > >> What does CMake think about rebasing? I much prefer to squash a branch >> like test-target_link_libraries into fewer commits so that eg adding >> newlines and changing tests to examine dashboard changes are not separate >> commits. I don't think those commits add value, but only noise. > > I agree. We have no problem with rewriting topics that have not yet been > merged to master. If you rewrite a topic such that the net change is the > same as what is already in next then it should merge cleanly. We have a > process during our merge meeting to identify pieces of next's history that > have been rewritten and exclude them from consideration for master. Cool, I've rebased and force pushed the branch now. >> Do I have karma to push -f to stage? > > Yes, but use with care. You can easily erase someone else's topic. > Also don't forget that the tip of the topic must be identical after > rewriting in order to merge cleanly to next with the old version. I accidentally'd this a little bit. My rewrite had some extra cleanups that were not already on the branch, so after I push -f'd, I couldn't merge it to next again. I just put the extra cleanups in another branch, merged that to next, and then was able to merge my cleaned up branch. So the net result currently should be a working clean branch. I think I read somewhere that next gets re-branched from master periodically. How often does that happen? Thanks, Steve. -- 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
[cmake-developers] Installing Qt5Config.cmake from the Qt repo?
Hi, == Summary == I'm considering adding some cmake files to Qt, which would be installed by Qt, and which would make it easier for CMake based projects to depend on Qt. I'm CC'ing the cmake developers too see what they think of the idea too. == Clarification == To avoid misunderstanding: * This proposal is not about porting the Qt build system to CMake. * This would not make Qt depend on CMake at all * I am proposing to add some plain text files to the Qt repo for installation * Those plain text files would need to be generated while building Qt (using existing mechanisms, like perl). == How CMake finds packages == (Skip this section if you already know how CMake finds packages) For those who have not used CMake before, it has two ways to find dependencies: * If you want to find a dependency, you write a Find.cmake file or use an existing one. Usually this Find.cmake will not be installed. * If you want to be easily found for others to depend on, you write a Config.cmake file and install it to a location CMake will use to find things like that. I assume this is similar to how pkgconfig works, but I have never used pkgconfig. This is most common in the case of projects which use CMake themselves, but there's no reason projects which do not use CMake can't provide similar files. This becomes even more useful with recent CMake features based on finding packages. Either way, if someone does this in CMake: find_package(Package) the result is the ability to use the headers and libraries from Package. CMake ships with FindQt4.cmake, so anyone using CMake uses find_package(Qt4) to be able to use Qt 4. == Qt5Config.cmake == I propose that we ship a Qt5Config.cmake file with Qt which we install, along with macros equivalent to what is currently in Qt4Macros.cmake, and some Targets.cmake files. Then find_package(Qt5) in CMake would use that Config file and there would be no need for a FindQt5.cmake. The advantage of this are: * It allows people using CMake to start experimenting with Qt 5 ports sooner * When new features arrive in Qt (such as new libraries like QtDeclarative was in Qt 4) we can update the Qt5Config file immediately and test the new features more easily. * We can use the cmake imported targets feature to more easily support debug and release versions on Windows. * KDE does not need a separate FindQt.cmake to the one shipped by CMake. == Maintainance == KDAB (specifically myself) can maintain these CMakes files. We have other engineers with both Qt and CMake competencies, and there are more people in the CMake and KDE communities with cross-competencies. That is assuming it works of course. I haven't even prototyped yet in case there is some reason this shouldn't be done. I'm quite confident it will work though. I can't think of any reason this effort should be prevented, but if you have a reason, please let me know. I'm looking for early objections before I start to do any work. Thanks, -- Stephen Kelly | Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions smime.p7s Description: S/MIME cryptographic signature -- 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
Re: [cmake-developers] [Development] Installing Qt5Config.cmake from the Qt repo?
On Friday, October 28, 2011 13:56:20 Thiago Macieira wrote: > On Friday, 28 de October de 2011 13:13:20 Stephen Kelly wrote: > > * If you want to be easily found for others to depend on, you write a > > > > Config.cmake file and install it to a location CMake > > will use> > > to find things like that. I assume this is similar to how pkgconfig > > works, but I have never used pkgconfig. > > Just like pkgconfig, I'd recommend that we make it one file per library, not > one global Qt5Config.cmake. What I want to investigate (I haven't yet, but I'm confident it will work) is if we can have both. We could have Qt5Core.cmake, Qt5Gui.cmake etc, and Qt5Config would be an aggregate which include()s the other configs based on the FIND_COMPONENTS. find_package(Qt5 COMPONENTS QtCore) or find_package(Qt5 COMPONENTS QtGui) for example. > Alternatively, let's be very clear: it's Qt5EssentialsConfig.cmake and it > includes NO other Qt addon. For those addons, they need to provide the > Config files themselves. Can you remind me where to find out what Qt5Essentials is or where I can find out? Searching in http://wiki.qt-project.org/ isn't throwing up anything. Is it roughly the contents of qtbase.git? Or does it include qtdeclarative.git too? Details like what would be included in Qt5Config could be discussed once there's some prototyping happening. I don't really feel strongly about it as long as it's roughly equivalent to what was made available by FindQt4.cmake. I'll wait a bit for other objections before prototyping though anyway. Then we can start looking at the real details. Thanks, -- Stephen Kelly | Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions signature.asc Description: This is a digitally signed message part. -- 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
Re: [cmake-developers] [Development] Installing Qt5Config.cmake from the Qt repo?
On Friday, October 28, 2011 16:24:08 Matt Williams wrote: > On 28 October 2011 14:44, wrote: > > > > I think that's reasonable in general. It's similar to what we do to > > support pkgconfig. I agree with Thiago's comment that this should be > > split and we should have one file per shared library. > > I think Stephen's suggestion of having one CMake file for all Qt > Essentials using find_package(Qt5 COMPONENTS QtGui etc...) makes the > most sense, at least for specifying which QtEssential libraries to > build against. It is the way most CMake files like this are done and > is not dissimilar to how the existing FindQt4.cmake works. Whether we > have a separate CMake file for Qt Addons (whether a separate one for > each module of another combined one) becomes a separate issue. Yes, that should certainly work. The idea of one config file per library should also work: find_package(Qt5Core) find_package(Qt5Gui) find_package(Qt5Widgets) then the contents of Qt5Config would look something like (CMake code): foreach(_component Qt5_FIND_COMPONENTS) if (_component MATCHES QtCore) find_package(Qt5Core NOMODULE) endif() # ... etc endforeach() Regarding what Qt5Config should be able to find, I would say that it should be able to find QtWidgets, which is not an essential module, but an addon in Qt 5. I'll prototype it next week and see how it goes. > > > How is this dependency wise? Would we need to install these files into a > > special location and how do we know where this location is? Does > > supporting the feature require cmake to be installed? > > From http://www.cmake.org/cmake/help/cmake2.6docs.html#command:find_package > (page down a little) you have a number of options of where to install > them. For example /(share|lib)/*/(cmake|CMake)/ where > could be /usr and could be 'Qt5' so they could be > installed in /usr/share/Qt5/cmake. There's similar special paths on > Windows and Mac. > > For the purpose of building and installing Qt we have no dependence on > CMake. As Stephen says the files could just be created from some > templates using a bit of Perl (or whatever you want). For someone > building a project which depends on Qt they would of course need CMake > to find these files. Yep, I have nothing more to add to this. Thanks, -- Stephen Kelly | Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions signature.asc Description: This is a digitally signed message part. -- 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
Re: [cmake-developers] [Development] Installing Qt5Config.cmake from the Qt repo?
On Friday, October 28, 2011 07:58:25 Clinton Stimpson wrote: > On Friday, October 28, 2011 06:21:23 am Stephen Kelly wrote: > > On Friday, October 28, 2011 13:56:20 Thiago Macieira wrote: > > > On Friday, 28 de October de 2011 13:13:20 Stephen Kelly wrote: > > > > * If you want to be easily found for others to depend on, you > > > > write a > > > > > > > > Config.cmake file and install it to a location > > > > CMake > > > > will use> > > > > > > > > to find things like that. I assume this is similar to how > > > > pkgconfig > > > > works, but I have never used pkgconfig. > > > > > > Just like pkgconfig, I'd recommend that we make it one file per > > > library, not one global Qt5Config.cmake. > > > > What I want to investigate (I haven't yet, but I'm confident it will > > work) is if we can have both. We could have Qt5Core.cmake, Qt5Gui.cmake > > etc, and Qt5Config would be an aggregate which include()s the other > > configs based on the FIND_COMPONENTS. > > > > find_package(Qt5 COMPONENTS QtCore) > > or > > find_package(Qt5 COMPONENTS QtGui) > > > > for example. > > > > > Alternatively, let's be very clear: it's Qt5EssentialsConfig.cmake > > > and it includes NO other Qt addon. For those addons, they need to > > > provide the Config files themselves. > > > > Can you remind me where to find out what Qt5Essentials is or where I can > > find out? Searching in http://wiki.qt-project.org/ isn't throwing up > > anything. Is it roughly the contents of qtbase.git? Or does it include > > qtdeclarative.git too? > > > > Details like what would be included in Qt5Config could be discussed once > > there's some prototyping happening. I don't really feel strongly about > > it > > as long as it's roughly equivalent to what was made available by > > FindQt4.cmake. > > > > I'll wait a bit for other objections before prototyping though anyway. > > Then we can start looking at the real details. > > > > Thanks, > > Absolutely no objections from me. I'm glad to see this happening, and am > glad to see the new open governance in Qt. > > Thank you. Cool, you're welcome. I've pushed my work in progress now to gitorious and will send an email about it shortly. > > Lately, there has been more work in FindQt4.cmake to make it more complete. > For example, there has been recent support for building with static plugins > and easy deployment with cpack. > > Have you thought about taking it that far? Yes, that is in scope for the CMake files in Qt I think, but I haven't worked on it yet. > > If you'd like, I can offer some review or input based on my experience > maintaining FindQt4.cmake. Thanks, I'll certainly get in touch when it's getting closer to ready. In the mean-time you can look at what I've done so far in the link in my next email. Thanks, -- Stephen Kelly | Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions signature.asc Description: This is a digitally signed message part. -- 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
Re: [cmake-developers] [Development] Installing Qt5Config.cmake from the Qt repo?
On Friday, October 28, 2011 13:13:20 Stephen Kelly wrote:
> == Summary ==
>
> I'm considering adding some cmake files to Qt, which would be installed by
> Qt, and which would make it easier for CMake based projects to depend on
> Qt.
>
> I'm CC'ing the cmake developers too see what they think of the idea too.
>From the feedback, it seems like this is a welcome idea. So I went ahead and
implemented it. My work is in the KDAB Qt5 clone on gitorious[1].
[1]https://qt.gitorious.org/+kdab-developers/qt/kdab-developers-
qtbase/commit/e79663d1352e7322839dfdfa2fa36bb30aaf4aac
At the moment it's a bit hacky but it does work on linux and it can be cleaned
up. At this point I'm looking for some initial feedback on the cmake
dependency (see below).
I was able to build a library in kdelibs framework branch with code similar
to:
find_package(Qt5 REQUIRED Core Gui Widgets)
include(${Qt5_USE_FILE})
add_library(itemmodels SHARED ${itemmodels_SRCS})
target_link_libraries(itemmodels
${Qt5Core_LIBRARY}
${Qt5Gui_LIBRARY}
${Qt5Widgets_LIBRARY}
)
So, as a proof of concept, I think I can call this a sucess.
>
> == Clarification ==
>
> To avoid misunderstanding:
>
> * This proposal is not about porting the Qt build system to CMake.
> * This would not make Qt depend on CMake at all
> * I am proposing to add some plain text files to the Qt repo for
> installation * Those plain text files would need to be generated while
> building Qt (using existing mechanisms, like perl).
In the branch, I do depend on cmake at configure-time to generate the Targets
files. These are platform specific files that cmake uses to build against
libraries in debug and release versions.
I would like to add this non-optional configure time dependency on cmake to Qt.
The alternative would be to maintain Targets files for multiple platforms by
generating those files at maintenance time (ie, running the script to generate
them, copy the result into place and check it in).
This maintenance burden is not really justifiable. The CMake dependency is
already available where Qt is available.
Depending on CMake would also mean that I could use configure_file() and
file(WRITE ...), which would make the stuff work across platforms already
(currently it depends on sed being available). So I would be able to clean up
the branch considerably.
Additionally, it would be easier to create a similar Config.cmake file for Qt
libraries outside of qtbase.git (such as QtWebKit) as I could simply install
the Qt5BasicConfig.cmake from qtbase and use it from the other repos.
I would make this dependency on CMake non-optional because it is important to
be able to use find_package(Qt5) without having to care about whether the
person who built it had cmake installed at the time. find_package(Qt5) needs
to work for each Qt5 build, so the config files need to be all the time.
Let me know if this is acceptable for Qt.
Thanks,
--
Stephen Kelly | Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions
signature.asc
Description: This is a digitally signed message part.
--
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
Re: [cmake-developers] cmake automoc breaks kde
On 11/02/2011 06:32 PM, David Faure wrote: On Monday 31 October 2011 21:47:31 Alexander Neundorf wrote: No, it's the other way around, in KDE. $ grep Q_OBJECT kautosavefile.* kautosavefile.h: Q_OBJECT $ grep moc kautosavefile.cpp #include "kautosavefile.moc" If it did additionally other things, this was more or less accidentially. How does qmake handle such cases ? Checking Indeed qmake expects moc_foo.cpp for the standard case (Q_OBJECT in header). This is why kde4automoc was made to support both moc filenames, so that it could be compatible with the kde way of doing it (foo.moc) and with the qmake way of doing it (moc_foo.cpp). Oh well, if you want to stick to that we'll change all of KDE, for the benefit of a clearer future indeed... At least it won't be an source incompatible change for app developers since they will have to enable CMAKE_AUTOMOC to get into this situation. Merely upgrading cmake or KDE (even to frameworks 5) won't trigger it. OK not exactly, find_package(kde4) will stop working so they will -have- to port to CMAKE_AUTOMOC, it will be the only solution available... If cmake in master is already doing what qmake does wrt the names of these files, and KDE wants the opposite, maybe we can make set(CMAKE_AUTOMOC_KDE_HACK ON) enable the opposite, and then we in KDE can actively port away from it without needing it immediately. Thanks, Steve. -- 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
Re: [cmake-developers] cmake automoc breaks kde
On 11/02/2011 06:32 PM, David Faure wrote: > > #include "foo.moc" > #include "moc_foo.cpp" > > This would have generated twice the same moc file, I think. IMO this is > really confusing. Well there is no reason to include both, unless you have Q_OBJECT in the .cpp file too:-) I'm sure I've seen this in several places in Qt code. Grepping I found one in qt48/src/scripttools/debugging/qscriptenginedebugger.cpp QT_END_NAMESPACE #include "qscriptenginedebugger.moc" #include "moc_qscriptenginedebugger.cpp" From memory, there are others. Thanks, Steve. -- 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
[cmake-developers] Can't push to master directly
Hi,
This page indicates that I should be able to push directly to master in the
official clone, but that seems to not be the case.
http://www.vtk.org/Wiki/CMake/Git#Publishing
stephen@hal:~/dev/src/cmake{master}$ git push official master
Counting objects: 7, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 370 bytes, done.
Total 4 (delta 3), reused 0 (delta 0)
W refs/heads/master cmake steve...@gmail.com DENIED by fallthru
error: hook declined to update refs/heads/master
To g...@cmake.org:cmake.git
! [remote rejected] master -> master (hook declined)
error: failed to push some refs to 'g...@cmake.org:cmake.git'
Does the wiki page need to have that section removed?
Thanks,
--
Stephen Kelly | Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions
smime.p7s
Description: S/MIME cryptographic signature
--
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
Re: [cmake-developers] Can't push to master directly
On Friday, November 04, 2011 17:43:38 David Cole wrote: > Why do you want to push directly? (Or were you just testing it because > you thought all CMake devs are "Authorized developers"...?) Yes, I was just testing it because I thought all CMake devs are authorized developers. I remember that part of the page confused me when I first started working with CMake git a few months ago, and I was looking at it again. Could it be an idea to split that page so that there is a page for people like me or new people which doesn't say anything about pushing to master? Thanks, -- Stephen Kelly | Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions signature.asc Description: This is a digitally signed message part. -- 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
[cmake-developers] Fwd: How to handle different cmake versions in extra-cmake-modules ?
Re-sending.
Original Message
Subject:How to handle different cmake versions in extra-cmake-modules ?
Date: Sat, 5 Nov 2011 16:45:44 +0100
From: Alexander Neundorf
Reply-To: neund...@kde.org
To: cmake-developers@cmake.org
CC: Stephen Kelly
Hi,
we (in KDE) are working on setting up a package/project "extra-cmake-modules"
which will provide additional cmake modules for other cmake-using projects,
mostly find-modules.
I don't really have a plan yet how to handle different cmake versions, etc.
I see at least the following three cases:
1) we may include modules, which do not exist in cmake.
2) we may include modules, which differ from versions in cmake. Using projects
should be able to decide whether they want to use the version from cmake or
from e-c-m on a file-by-file basis.
3) we may include modules, which do not exist in cmake up to some version, but
then they were added to cmake. Users of such a newer cmake version should get
the version from cmake.
I assume that a directory which contains the modules from e-c-m is added to
CMAKE_MODULE_PATH, something like:
find_package(extra-cmake-modules REQUIRED)
set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} ${ECM_MODULE_DIRECTORY} )
Case 1 is simple. The using project uses the module or not.
Case 2 is not so simple. One idea I have is to have the using project specify
explicitely which files they need, e.g. something like
find_package(extra-cmake-modules REQUIRED)
ecm_copy_modules(${CMAKE_BINARY_DIR}/modules FindFoo.cmake
FindBlub.cmake
ECMDoSomething.cmake)
set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} ${CMAKE_BINARY_DIR}/modules} )
This macro would copy just these needed files into the given directory, which
can then be added to CMAKE_MODULE_PATH.
Case 3. I don't really have an idea yet. Add some code at the top of each file
which include()s the file from cmake if the version is bigger than some
specified version ?
Something like:
FindBlub.cmake:
if(CMAKE_VERSION> 2.8.12)
include(${CMAKE_ROOT}/Modules/FindBlub.cmake)
return()
endif()
Ideas, comments, etc. ?
Thanks
Alex
--
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
[cmake-developers] target_include_directories branch in stage
Hi,
As discussed on the cmake user mailing list, I'm interesting in implementing
the feature of target specific and configuration specific include
directories.
http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/39090/focus=39114
I've pushed the target-include-directories branch to stage, which implements
the feature. I started out as prototyping, but I ended up implementing API
that I think makes sense. I have not merged it into next yet as it is not
certain if it should be in the next release. I'd prefer it to be though if
we can sort out the issues with what should be the target feature set.
David mentioned one issue is whether the include directories of a target
property should overwrite those of the directory property (added with the
command include_directories). Like others on the other thread, I would
expect the final list of includes to be determined by addition. For example:
project(foo)
include_directories(${bar_INCLUDES})
add_library(foo_lib ...)
target_include_directories(foo CONFIG_TYPE DEBUG debug_helper.h)
The target_include_directories command there shouldn't overwrite the
${bar_INCLUDES}. I can't think of any case where that would be wanted.
The implementation in my branch so far makes the following possible:
** Both ${bar_INCLUDES} and ${spam_INCLUDES} are used when building foo.
Only ${bar_INCLUDES} are available when building ham.
include_directories(${bar_INCLUDES})
add_library(foo ...)
target_include_directories(foo ${spam_INCLUDES})
add_library(ham ...)
** ${spam_INCLUDES} appear before ${bar_INCLUDES} when building foo.
include_directories(${bar_INCLUDES})
add_library(foo ...)
target_include_directories(foo BEFORE ${spam_INCLUDES})
** Includes appear in the order spam > bar > yam when building foo.
include_directories(${bar_INCLUDES})
add_library(foo ...)
target_include_directories(foo BEFORE ${spam_INCLUDES})
target_include_directories(foo ${yam_INCLUDES})
** Includes appear in the order spam > par > bar > yam when building foo.
include_directories(${bar_INCLUDES})
include_directories(BEFORE ${par_INCLUDES})
add_library(foo ...)
target_include_directories(foo BEFORE ${spam_INCLUDES})
target_include_directories(foo ${yam_INCLUDES})
** ${yam_INCLUDES} are used when building foo in all configurations.
${spam_INCLUDES} are used only when CMAKE_BUILD_TYPE == Debug.
add_library(foo ...)
target_include_directories(foo CONFIG_TYPE DEBUG ${spam_INCLUDES})
target_include_directories(foo ${yam_INCLUDES})
** ${yam_INCLUDES} are used when building foo in all configurations.
${spam_INCLUDES} are used only when CMAKE_BUILD_TYPE == Debug,
and they appear before the ${yam_INCLUDES} (and the directory level
includes)
add_library(foo ...)
target_include_directories(foo BEFORE CONFIG_TYPE DEBUG ${spam_INCLUDES})
target_include_directories(foo ${yam_INCLUDES})
The only thing potentially missing is a way to insert includes BEFORE others
in the target include directories, but after the directory level includes. I
can't think of any reason to want that and not simply be able to move the
invokations of target_include_directories around. ie,
target_include_directories(foo ${spam_INCLUDES})
target_include_directories(foo ${yam_INCLUDES})
instead of
target_include_directories(foo ${yam_INCLUDES})
target_include_directories(foo ${spam_INCLUDES})
I imagine that in every case, the person writing those lines 'owns' foo, so
they can control the positions of those lines.
The bugs David listed in the other thread are:
- http://public.kitware.com/Bug/view.php?id=1968
* Partially solved by this branch. Bug also requests source level includes.
- http://public.kitware.com/Bug/view.php?id=6269
* Partially solved by this branch. Bug also requests config level
link_directories and link libraries
- http://public.kitware.com/Bug/view.php?id=6493
* Not affected by this branch as far as I see.
- http://public.kitware.com/Bug/view.php?id=8189
* Not affected by this branch as far as I see. Bug requests source-level
include directories.
Issues:
* I have only tried to implement this with the makefile generator and have
so far only tested it with "Unix Makefiles". One of the bugs says XCode
can't do source-level includes. Can it do target-level includes? Would I
have to implement this for all generators before it would be considered for
acceptance?
* There's scope for refactoring the new code in my branch as well as
potentially refactoring with the cmIncludeDirectoriesCommand.
* There's scope for optimization.
* I haven't written any tests yet.
So before I merge this into next, I'm wondering if this feature can be
considered for inclusion in 2.8.7?
Thanks,
Steve.
--
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
Re: [cmake-developers] target_include_directories branch in stage
Stephen Kelly wrote: > Issues: > * I have only tried to implement this with the makefile generator and have > so far only tested it with "Unix Makefiles". One of the bugs says XCode > can't do source-level includes. Can it do target-level includes? Would I > have to implement this for all generators before it would be considered > for acceptance? > * There's scope for refactoring the new code in my branch as well as > potentially refactoring with the cmIncludeDirectoriesCommand. > * There's scope for optimization. > * I haven't written any tests yet. > Related to Alex's remarks, there may also be scope for PUBLIC_INCLUDES and PRIVATE_INCLUDES keywords. http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/39090/focus=39200 Thanks, Steve. -- 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
[cmake-developers] Should sucessive calls to find_package for one package succeed?
Hi,
Should successive calls to find_package succeed in general?
Eg
find_package(Grantlee COMPONENTS Templates)
find_package(Grantlee COMPONENTS TextDocument)
?
Currently if the target package uses Config files and
install(TARGETS ... EXPORT)
the convention is to use
include(${CMAKE_CURRENT_LIST_DIR}/GrantleeTargets.cmake)
in the config file. The problem is that that Targets file uses an unguarded
ADD_LIBRARY(grantlee_templates SHARED IMPORTED)
which cmake errors on:
add_library cannot create imported target "grantlee_templates" because
another target with the same name already exists.
The fix appears to be to wrap the call to add_library:
if (NOT TARGET grantlee_templates)
ADD_LIBRARY(grantlee_templates SHARED IMPORTED)
endif()
I can fix this if it is a bug.
Thanks,
Steve.
--
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
Re: [cmake-developers] Should sucessive calls to find_package for one package succeed?
Brad King wrote:
> On 11/6/2011 7:00 PM, Stephen Kelly wrote:
>> include(${CMAKE_CURRENT_LIST_DIR}/GrantleeTargets.cmake)
>
> It is up to the author of the config file to block this correctly
> against multiple inclusion, e.g.
>
> if(NOT Grantlee_TARGETS_INCLUDED)
> set(Grantlee_TARGETS_INCLUDED 1)
> include(${CMAKE_CURRENT_LIST_DIR}/GrantleeTargets.cmake)
> endif()
Ok, thanks. Seems like an important thing to document. Is there any page
showing how to use config files and targets files? I only found out how to
use them by talking to Alex :).
>
>> if (NOT TARGET grantlee_templates)
>>ADD_LIBRARY(grantlee_templates SHARED IMPORTED)
>> endif()
>
> This would hide cases of accidentally conflicting target names.
>
I don't understand. You mean if someone called install(EXPORTS) with the
wrong target?
Thanks,
Steve.
--
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
Re: [cmake-developers] target_include_directories branch in stage
Brad King wrote: > On 11/6/2011 5:45 PM, Stephen Kelly wrote: >> As discussed on the cmake user mailing list, I'm interesting in >> implementing the feature of target specific and configuration specific >> include directories. > > Thanks for working on this. Thanks for the feedback. > The INCLUDE_DIRECTORIES property of a target must be the *only* list > from which the final include directory list is constructed. When a target > is created the current directory-level include directories must be used > to initialize the list. Further include_directories() calls in the same > directory must append not only to the directory-level list but also to > the property for all existing targets. At any intermediate point a > target's property can be modified independently (see the set_property > command example below). Yes, it should be possible to do this. I'll try it out. > Now we can return to per-config include directories. To incorporate them > into the same single list, we will need some kind of markup on a per-entry > basis. This is similar to the "debug/optimized" keywords used by the > target_link_libraries command, but must be more well designed. Perhaps > a syntax similar to generator expressions in custom commands can work. > I'll have to think more about it. Ok. I thought the BEFORE keyword for target_include_directories would be useful there, but if there's a better way to do it, that's fine with me too. Thanks, Steve. -- 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
Re: [cmake-developers] target_include_directories branch in stage
Alexander Neundorf wrote:
>> For example:
>>
>> project(foo)
>> include_directories(${bar_INCLUDES})
>> add_library(foo_lib ...)
>> target_include_directories(foo CONFIG_TYPE DEBUG debug_helper.h)
>
> Do you think a new command is necessary, and set_property(TARGET ... ) is
> not good enough ?
I initially got it working just with the set_property command, but I
introduced the new custom command so that I could introduce the BEFORE
keyword.
A PREPEND keyword for set_property might be a better option.
Thanks,
Steve.
--
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
[cmake-developers] Copyright.txt out of date.
Hi, I'm copying Qt4Macros.cmake into Qt and in copying the content of Copyright.txt that it contains: Copyright 2000-2009 Kitware, Inc., Insight Software Consortium All rights reserved. Shouldn't this be updated to 2011? -- 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
Re: [cmake-developers] Copyright.txt out of date.
Brad King wrote: > On 11/10/2011 7:47 AM, Stephen Kelly wrote: >> I'm copying Qt4Macros.cmake into Qt and in copying the content of >> Copyright.txt that it contains: >> >> Copyright 2000-2009 Kitware, Inc., Insight Software Consortium >> All rights reserved. >> >> Shouldn't this be updated to 2011? > > Thanks: > >http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ac39e9c7 Thanks. > > However, you should look at the header used in other Modules. The > copyright of contributed modules is retained by the original authors. > Also make sure the ModuleNotices test passes for you. > I'm not sure what you mean. You mean I should look at the history of the macros and guess updates to the copyright header? And I should submit that as a patch to CMake? I can see who the authors were, but I can't know if the author was working under the employment of Kitware at the time or any other company who owns the copyright of work done on work time (author != copyright holder). I'll make sure to copy the correct copyright attribution notices if Qt4Macros.cmake is changed, but I don't think I should be the one to add copyright notices for other people. Currently the file has 'Copyright 2005-2009 Kitware, Inc.' at the top. Am I misunderstanding something? Thanks, Steve. -- 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
Re: [cmake-developers] cmake automoc breaks kde
On 11/10/2011 10:16 PM, Alexander Neundorf wrote:
On Wednesday 02 November 2011, David Faure wrote:
On Monday 31 October 2011 21:47:31 Alexander Neundorf wrote:
On Monday 31 October 2011, David Faure wrote:
This is a typical (kde) case where the .cpp incudes the .moc, for the
object defined in the .h.
Shouldn't it include moc_kauthactionwatcher.cpp ?
No, that's for the case where the qobject is in the .cpp file.
Is this really a typical case, i.e. is that done in many places ?
Yes. Just grep for moc includes in kde...
I thought the rule is that if there is a include foo.moc, the Q_OBJECT is
in the same cpp file.
No, it's the other way around, in KDE.
$ grep Q_OBJECT kautosavefile.*
kautosavefile.h:Q_OBJECT
$ grep moc kautosavefile.cpp
#include "kautosavefile.moc"
If it did additionally other things, this was more or less accidentially.
But it was the way kdesupport/automoc always worked, on purpose, not
accidentally.
OK, more precisely: it didn't care what the name of the included moc file
was, what mattered was, where is Q_OBJECT being used.
As the kde4automoc.cpp code says: when parsing the .cpp file:
// If the moc include is of the moc_foo.cpp style we expect the Q_OBJECT
class // declaration in a header file.
// If the moc include is of the foo.moc style we need to look for a
Q_OBJECT // macro in the current source file, if it contains the macro we
generate the // moc file from the source file, else from the header.
The logic which is currently implemented is:
1. if foo.cpp includes foo.moc, run moc on foo.cpp and generate foo.moc
That should depend on if foo.cpp actually says Q_OBJECT or not. Otherwise
this .moc should be created from the header file. Not much point in running
moc over a .cpp that doesn't define a Q_OBJECT :)
2. run moc on all header files bar.h which contain "Q_OBJECT" and
generate moc_bar.cpp from them
That could be moc_bar.cpp or bar.moc depending on which one is included.
(which in detail means:
2.1 for every included moc_xyz.cpp (no matter in which file), search for
a corresponsing xyz.h/hxx/hpp file and run moc on it
2.2 for every bar.cpp file, check whether there is a corresponding
bar.h/hpp/hxx file and collect it
2.3 check for a Q_OBJECT macro in all collected header files and all
header files listed explicitely as a source for the target, and run moc
on them. If the resulting moc_xyz.cpp file has not been included in any
source file, include it in_automoc.cpp, which is built as
part of the target )
Step 2.2 already involves guessing, which I don't like.
Beside that, IMO these are clear rules, which are easy to understand.
With the old behaviour it was actually ambigous:
foo.h:
class Foo
{
Q_OBJECT
};
foo.cpp:
Foo::Foo() {}
#include "foo.moc"
#include "moc_foo.cpp"
This would have generated twice the same moc file, I think. IMO this is
really confusing.
Well there is no reason to include both, unless you have Q_OBJECT in the
.cpp file too :-)
Now it is simple: foo.moc from foo.cpp, moc_foo.cpp from foo.h.
If this is really done in many places in KDE, I'll add some workaround,
but I think the default behaviour should stay as it is now in cmake git.
How does qmake handle such cases ?
Checking
Indeed qmake expects moc_foo.cpp for the standard case (Q_OBJECT in
header). This is why kde4automoc was made to support both moc filenames,
so that it could be compatible with the kde way of doing it (foo.moc) and
with the qmake way of doing it (moc_foo.cpp).
Oh well, if you want to stick to that we'll change all of KDE, for the
benefit of a clearer future indeed... At least it won't be an source
incompatible change for app developers since they will have to enable
CMAKE_AUTOMOC to get into this situation. Merely upgrading cmake or KDE
(even to frameworks 5) won't trigger it. OK not exactly,
find_package(kde4) will stop working so they will -have- to port to
CMAKE_AUTOMOC, it will be the only solution available...
Please give the RestoreAutmocKDECompatibility branch on cmake stage a try.
It should work again, but print a warning if a file includes a moc_foo.cpp,
but no foo.moc, and contains a Q_OBJECT macro.
For Qt5 I'd prefer to not support that anymore.
I.e. moc_foo.cpp -> header, foo.moc -> source file.
Alex
I tried that branch. It doesn't build the frameworks branch for me. Does
it work for you?
There seems to be several problems:
* KDE does include "foo.moc" if it wants the header file to be moc'd.
This is 'incorrect' compared to what qmake expects, which would be a
"moc_foo.cpp" include.
* Some places in KDE use include "moc_foo.cpp" 'correctly', but there
are only about 10 occurrences. The current automoc tool seems to handle
that, as does cmake 2.8.6 apparently.
* KDE does include "foo_test.moc" in foo_test.cpp to moc the test object
in foo_test.cpp. This is 'correct' compared to what qmake does.
* KDE does eg, include "kjob_p.moc" in kjob.cpp to cause kjob_p.h to be
moc'd. The RestoreAutmocKDECompatibilit
Re: [cmake-developers] [CMake 0012588]: install(EXPORTS) does not work well with dependencies
> In KDE we're starting to use install(EXPORTS) and config files. We are > building libraries with dependencies on one another which are in different > export sets. > > Different export sets are needed to create different Targets files, which > can be included in different Config files. If the attached example were > more complete, there would be a oneConfig.cmake which includes > oneDeps.cmake, and a twoConfig.cmake which includes twoDeps.cmake. > > At cmake time we get this error: > > CMake Error: INSTALL(EXPORT "twoDeps" ...) includes target "libtwo" which > requires target "libone" that is not in the export set. > > How can we resolve this? http://public.kitware.com/Bug/view.php?id=12588 Brad asked to bring this up on the list for discussion. Is this situation resolvable? Thanks, Steve. -- 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
Re: [cmake-developers] Multiple dependent install(EXPORT) sets
Brad King wrote: > On 11/22/2011 9:31 AM, Stephen Kelly wrote: >>> CMake Error: INSTALL(EXPORT "twoDeps" ...) includes target "libtwo" >>> which requires target "libone" that is not in the export set. >>> >>> How can we resolve this? >> >> http://public.kitware.com/Bug/view.php?id=12588 >> >> Brad asked to bring this up on the list for discussion. > > Additional CMake development is needed to support this. We need to > introduce the notion of multiple dependent install(EXPORT) sets. > > I think the commands will look something like this: > >add_library(A ...) >add_library(B ...) >target_link_libraries(B A) >install(TARGETS A ... EXPORT ExportA) >install(TARGETS B ... EXPORT ExportB) >install(EXPORT ExportA ...) >install(EXPORT ExportB DEPENDS ExportA ...) > > The "DEPENDS ExportA" option to install(EXPORT) on the last line will need > to > be added and implemented. We will have to require that the > install(EXPORT) > commands be invoked in dependency order (ex. A before B). That way when > the command installing ExportB is writing library B's dependency on A, it > can transform the name using the options that had been given to the > install > command for ExportA, such as its NAMESPACE. Furthermore, the targets file > generated for ExportB will need to include() the file generated for > ExportA using the DESTINATION given to the latter to make its targets > available. And its FILE presumably, but why? This ties in to the question of whether find_package(B) should find the dependencies of B: case 1: project(big_project) find_package(A) // Uses AConfig.cmake, which includes ATargets.cmake find_package(B) // Uses BConfig.cmake, which includes BTargets.cmake case 2: project(big_project) find_package(B) // Uses BConfig.cmake, which includes BTargets.cmake // and ATargets.cmake, but there was no find_package(A), // so this is broken anyway. case 3: project(big_project) find_package(B) // Uses BConfig.cmake, which runs find_package(A), // includes BTargets.cmake and ATargets.cmake, despite the // fact that, find_package(A) has the effect of including it // anyway. -- 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
Re: [cmake-developers] cmake automoc breaks kde
On 11/22/2011 06:20 PM, Alexander Neundorf wrote: Using Qt5 or Qt4 ? Qt4. There seems to be several problems: * KDE does include "foo.moc" if it wants the header file to be moc'd. This is 'incorrect' compared to what qmake expects, which would be a "moc_foo.cpp" include. Yes. * Some places in KDE use include "moc_foo.cpp" 'correctly', but there are only about 10 occurrences. The current automoc tool seems to handle that, as does cmake 2.8.6 apparently. I thought about this. There are 4 constellations, and only one constellation where things can break: * foo.cpp includes neither foo.moc nor moc_foo.cpp. No problem. Sort of. There are cases where the moc file must be included in the cpp file (see below). But this removal of includes is what we should aim for in KDE. I think if the options are: 1) Introduce odd hacky KDE specific workarounds to CMake 2) Remove the problematic includes from KDE files in the frameworks branch I will side with option 2). CMAKE_AUTOMOC is not used in KDE4. The feature is only really relevant to non KDE Qt4 users. Let's just 'fix the bug' in the frameworks iteration of kdelibs. * if foo.cpp includes both foo.moc and moc_foo.cpp, then both foo.h and foo.cpp will be moc'ed, and it doesn't matter which one is for which. No problem. It seems there is a test missing for this case. Yes. * if foo.cpp includes only foo.moc, then foo.cpp will be moc'ed. This may be unnecessary, but shouldn't create problems. If foo.h also needs to be moc'ed, it will be, and the resulting moc_foo.cpp will be included in the target_automoc.cpp file. So it should also work. This is Tests/QtAutomoc/codeeditor.cpp Sort of. There are cases where the moc file must be included in the cpp file, because it needs definitions from the .h file. (eg, use of the Q_PRIVATE_SLOT macro). If a KDE developer included foo.moc expecting that to be the result of moc'ing the .h file, the build will fail. In this case, foo.cpp needs to be fixed to include "moc_foo.cpp" instead. I don't think CMake should introduce a hack for this. * problematic case: if foo.cpp includes only moc_foo.cpp, then cmake will check whether foo.cpp contains "Q_OBJECT". If it does, it will: ** fail with Qt5, stating that foo.cpp contains Q_OBJECT but does not include foo.moc, so it can't work I think this is fine. ** warn with Qt4 that it will run moc on foo.cpp instead of foo.h to generate moc_foo.cpp This is Tests/QtAutomoc/blub.cpp * KDE does include "foo_test.moc" in foo_test.cpp to moc the test object in foo_test.cpp. This is 'correct' compared to what qmake does. Yes. * KDE does eg, include "kjob_p.moc" in kjob.cpp to cause kjob_p.h to be moc'd. The RestoreAutmocKDECompatibility branch introduces a commit which makes this not work because the source file has a different basename. Yes. I did not expect somebody would be doing this. I don't want to support this for Qt5. I can add a fix with a warning for Qt4. This is not uncommon in both KDE and in Qt itself, or any other project where it makes sense to put a QObject-inherited class in the _p.h as an internally used class. See for example, qplaintextedit.cpp: #include "moc_qplaintextedit.cpp" #include "moc_qplaintextedit_p.cpp" This should be supported by the automoc feature. I have also seen places (I think in QtDeclarative) where a foo.cpp file included the file moc_bar.cpp, though that is very uncommon. The logic that I would use would be something like: find #include "moc_(.*).cpp" -> generate moc for "\\1.h" find #include "(.*).moc" -> generate moc for "\\1.cpp" Was there a reason for preventing this? I think we need to have a list of exactly what cases should be supported, This is the current documentation of automoc in cmake. I was hoping it would be relatively clear: "If an #include statement like #include \"moc_foo.cpp\" is found," "the Q_OBJECT class declaration is expected in the header, and moc is" "run on the header file." "If an #include statement like #include \"foo.moc\" is found," "then a Q_OBJECT is expected in the current source file and moc" "is run on the file itself." "Additionally, all header files are parsed for Q_OBJECT macros," "and if found, moc is also executed on those files. The resulting" "moc files, which are not included as shown above in any of the source" "files are included in a generated_automoc.cpp file, " "which is compiled as part of the target." This should be compatible to qmake, and this is what I'd like to support for Qt5. Nearly. As you can see, there are quite some differences compared to the qmake behavior. and fix KDE to do the right thing. I think in many cases, fixing KDE will just be removing the explicit include "foo.moc" which is intended to run moc on foo.h, and let the automatic moc'ing do the work. If any other 'KDE compatilbility' features are in cmQtAutomoc which differ from qmake behavior, I really think it should be behind an option which is off by default, whic
Re: [cmake-developers] Multiple dependent install(EXPORT) sets
Alexander Neundorf wrote: > On Tuesday 22 November 2011, Brad King wrote: >> On 11/22/2011 10:03 AM, Stephen Kelly wrote: >> > Brad King wrote: >> >> We will have to require that the install(EXPORT) >> >> commands be invoked in dependency order (ex. A before B). That way >> >> when the command installing ExportB is writing library B's dependency >> >> on A, it can transform the name using the options that had been given >> >> to the install command for ExportA, such as its NAMESPACE. >> >> This is required because ExportB will create an imported target for >> library B and that imported target will list its dependency on an >> imported target >> for library A. What is that imported target called? Where is it >> defined? >> Only ExportA knows, and then only after its install(EXPORT) has been >> called. > > Yes. > > Where/why is it actually necessary to split libraries installed from one > package into multiple Config.cmake files ? > This is now to install separate libraries from a big kdelibs, right ? > Maybe we (KDE) simply shouldn't do this, and just start with it once the > big modules are broken into separate parts. Maybe. Should nobody install multiple 'modular pieces' from one top level CMakeLists.txt? It's sort of superbuild without superbuild, but with the advantage that the sources are in the source directory. > Then each of the smaller parts can install a Config.cmake file for all its > libraries. If e.g. libkgui depends on libkcore, currently those two > targets would exist in one project, but installed as two export sets. > Once they are separated into two projects, then libkgui depends already on > the imported target KDE::kcore (or how it is named), and referencing this > in its Targets.cmake file works fine. Does a target know its imported target name or is it really just the export mechanism? Would it be possible for the export mechanism to inform the targets of their imported target name and location so that that information can be retrieved by dependents? Consider this: add_library(bar) add_library(foo) target_link_libraries(foo bar) install(TARGETS bar EXPORT barTargets ...) install(TARGETS foo EXPORT fooTargets ...) install(EXPORTS barTargets NAMESPACE myNS) # sets a property on bar that its # imported name is myNS::bar install(EXPORTS fooTargets NAMESPACE otherNS) # Maps from the LINK_LIBRARIES # information 'bar' to # 'myNS::bar' to populate the # dependency information This also removes the need for explicit dependencies between install(EXPORTS) invocations, which is already implicitly specified by the (public) link interface of targets build in the same build system. > We do this already with Qt4. You mean in FindQt4.cmake? I'm not sure it's the same situation. > >> >> Furthermore, the targets file >> >> generated for ExportB will need to include() the file generated for >> >> ExportA using the DESTINATION given to the latter to make its targets >> >> available. >> > >> > And its FILE presumably, but why? This ties in to the question of >> > whether >> >> > find_package(B) should find the dependencies of B: >> We could leave this part out and leave it up to the Config.cmake file >> author to ensure ExportA's targets file is loaded when ExportB's targets >> file is loaded. > Why the Config file author? Why not the consumer of the config files? You mean that the author of BConfig.cmake should ensure that ExportA's targets file is loaded? How would it do that without a find_package(A)? Thanks, Steve. -- 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
Re: [cmake-developers] cmake automoc breaks kde
On 11/22/2011 07:10 PM, Alexander Neundorf wrote: > find #include "(.*).moc" -> generate moc for "\\1.cpp" > Was there a reason for preventing this? We can do that, but how can that work ? I mean, this will generate code for a class which is declated in a different source file, so it is unknown in the including file, no ? You're right sorry, I was just cut+paste+modifying. If #include "(.*).moc" CMAKE_MATCH_1 MATCHES basename, then moc self I guess. -- 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
Re: [cmake-developers] cmake automoc breaks kde
On 11/22/2011 07:37 PM, David Faure wrote:
On Tuesday 22 November 2011 14:33:25 Stephen Kelly wrote:
I think in many cases,
fixing KDE will just be removing the explicit include "foo.moc" which is
intended to run moc on foo.h, and let the automatic moc'ing do the work.
No, to include moc_foo.cpp instead, if that's what cmake automoc would
generate.
If you don't include any moc, then the moc is compiled separately, which leads
to slower compilation.
Are you sure? I think all moc files of a target which are not included
elsewhere are included in a _automoc.cpp file, which is then built as
the automoc target. See ${kdeui_BUILD_DIR}/kdeui_automoc.cpp for example.
There should be no slowdown AFAICT.
--
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
Re: [cmake-developers] cmake automoc breaks kde
Alexander Neundorf wrote: > Test added, works. > What is not working right now is including someotherfile.moc. I could add > special handling for including thisfile_p.moc (as opposed to > moc_thisfile_p.cpp, which works). Yes, this is the issue that makes the build break in the frameworks branch. It is mostly all breakage due to the thisfile_p.moc issue and expecting thisfile.moc to run moc on the .h file. All can be considered incorrect in frameworks IMO and I can fix them there. I'll just have to make sure that they also work with cmake 2.8.6. Thanks, Steve. -- 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
Re: [cmake-developers] cmake automoc breaks kde
On 11/22/2011 08:43 PM, Alexander Neundorf wrote: On Tuesday 22 November 2011, Stephen Kelly wrote: On 11/10/2011 10:16 PM, Alexander Neundorf wrote: ... Please give the RestoreAutmocKDECompatibility branch on cmake stage a try. It should work again, but print a warning if a file includes a moc_foo.cpp, but no foo.moc, and contains a Q_OBJECT macro. For Qt5 I'd prefer to not support that anymore. I.e. moc_foo.cpp -> header, foo.moc -> source file. Alex I tried that branch. It doesn't build the frameworks branch for me. I found the mistake ! When I wrote that mail two weeks ago it was the RestoreAutmocKDECompatibility branch. This got merged into master in the meantime. Once your Qt5 branch was merged, I created a new branch named AutomocIncludedDotMocFileHandling. This is the branch I'm talking about. Alex Actually I've been using that branch all along. Now when I try to build the frameworks branch using the cmake next branch, I get: AUTOMOC: error: /home/stephen/dev/src/kf5/tier1/libkcoreaddons/src/io/kdirwatch.cpp: The file includes the moc file "kdirwatch_p.moc", which seems to be the moc file from a different source file. This is not supported. Include "kdirwatch.moc" to run moc on this source file. I then get a good deal of /home/stephen/dev/src/kf5/tier1/libkauth/HelperProxy.cpp:0: Note: No relevant classes found. No output generated. Generating FakeHelperProxy.moc /home/stephen/dev/src/kf5/tier1/itemmodels/src/kcheckableproxymodel.cpp:0: Note: No relevant classes found. No output generated. Generating moc_kdescendantsproxymodel.cpp /home/stephen/dev/src/kf5/tier1/libkauth/backends/fakehelper/FakeHelperProxy.cpp:0: Note: No relevant classes found. No output generated. The warnings are good because they indicate doing it the wrong way. As I noted in the other mail, I'll fix these issues in the frameworks branch. Do you want testcases for them in cmake to workaround it there? -- 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
Re: [cmake-developers] cmake automoc breaks kde
On 11/22/2011 10:03 PM, Alexander Neundorf wrote: Now when I try to build the frameworks branch using the cmake next branch, I get: AUTOMOC: error: /home/stephen/dev/src/kf5/tier1/libkcoreaddons/src/io/kdirwatch.cpp: The file includes the moc file "kdirwatch_p.moc", which seems to be the moc file from a different source file. This is not supported. Include "kdirwatch.moc" to run moc on this source file. I added special handling now for the case that basename_p.moc is included with Qt4. Your new commits work with the parts of the frameworks branch affected by this, yes. However, there are still many places where the foo.moc file is expected to be the result of moc'ing the header, which causes errors like this: In file included from /home/stephen/dev/build/qt48/kf5/tier1/libkdbus/kdbus_automoc.cpp:2:0: /home/stephen/dev/build/qt48/kf5/tier1/libkdbus/moc_kdbusinterprocesslock.cpp: In static member function 'static void KDBusInterProcessLock::qt_static_metacall(QObject*, QMetaObject::Call, int, void**)': /home/stephen/dev/build/qt48/kf5/tier1/libkdbus/moc_kdbusinterprocesslock.cpp:55:22: error: invalid use of incomplete type 'struct KDBusInterProcessLockPrivate' /home/stephen/dev/build/qt48/kf5/tier1/libkdbus/../../../../../src/kf5/tier1/libkdbus/kdbusinterprocesslock.h:30:7: error: forward declaration of 'struct KDBusInterProcessLockPrivate' Fixed by changing the include from foo.moc to moc_foo.cpp of course. This is due to the use of Q_PRIVATE_SLOT. I've just added a testcase to the branch. I then get a good deal of /home/stephen/dev/src/kf5/tier1/libkauth/HelperProxy.cpp:0: Note: No relevant classes found. No output generated. Generating FakeHelperProxy.moc /home/stephen/dev/src/kf5/tier1/itemmodels/src/kcheckableproxymodel.cpp:0: Note: No relevant classes found. No output generated. Generating moc_kdescendantsproxymodel.cpp /home/stephen/dev/src/kf5/tier1/libkauth/backends/fakehelper/FakeHelperProx y.cpp:0: Note: No relevant classes found. No output generated. The warnings are good because they indicate doing it the wrong way. As I noted in the other mail, I'll fix these issues in the frameworks branch. Do you want testcases for them in cmake to workaround it there? Please have a look at the current AutomocIncludedDotMocFileHandling branch and see if there are still things missing. I'll try building frameworks and see what still fails. I do get an error in solid which again is due to including the foo.moc file and expecting that to be the result of moc'ing the header. It only works currently due to a quirk in the include order in that file, so I don't think it's worth working around or testing. Thanks, Steve. -- 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
[cmake-developers] Generating imported library targets without the cmake executable
Hi there,
I am working on installing CMake config files from the Qt repository so that
there is less need for a FindQt.cmake.
The motivation is that between releases of Qt and CMake, the features of Qt
get out of sync with the features available through FindQt.cmake, but with
config files that is not the case. Additionally, as the Qt buildsystem knows
everything about the package it is creating, it is possible to create config
files that already 'know the answers' and locations of everything without
having to find+query.
The previous discussion on this is here:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/2090
the current candidate for inclusion in Qt is here (which requires an account
in the Qt jira):
http://codereview.qt-project.org/#change,8518
and here (which does not):
https://qt.gitorious.org/+kdab-developers/qt/kdab-developers-
qtbase/commit/913fd3a1acffbae2ca8f6967dd951a03ff9f76a4
There is a small sticking point to this being in a finished state:
In creating the imported targets, I attempt to create the same content as
cmake creates when using install(EXPORTS). So I generate something along
these lines:
get_filename_component(_qt5_install_prefix
${CMAKE_CURRENT_LIST_DIR}/../../../ ABSOLUTE)
set_property(TARGET Qt5Core APPEND PROPERTY IMPORTED_CONFIGURATIONS DEBUG)
set_target_properties(Qt5Core PROPERTIES
IMPORTED_LINK_INTERFACE_LIBRARIES_DEBUG ""
IMPORTED_LOCATION_DEBUG "${_qt5_install_prefix}/lib/libQtCore.so.5.0.0"
IMPORTED_SONAME_DEBUG "libQtCore.so.5"
)
set_property(TARGET Qt5Core APPEND PROPERTY IMPORTED_CONFIGURATIONS RELEASE)
set_target_properties(Qt5Core PROPERTIES
IMPORTED_LINK_INTERFACE_LIBRARIES_RELEASE ""
IMPORTED_LOCATION_RELEASE
"${_qt5_install_prefix}/lib/libQtCore.so.5.0.0"
IMPORTED_SONAME_RELEASE "libQtCore.so.5"
)
That is, I generate the full file name for the IMPORTED_LOCATION including
the library prefix and suffix, which are also used for the IMPORTED_SONAME.
QMake does not provide the library prefix and suffix used in variables, as
cmake does, but I believe there is also no way to change them in qmake. As a
result I hardcode the prefixes and suffixes for windows/linux/max - .dll,
.so etc.
The Qt QMake maintainer does not like this, and requests that CMake
determines the prefix and suffix instead. Does CMake provide any way for me
to get the default prefix and suffix for libraries? If it does then I could
generate something like this instead:
IMPORTED_SONAME "${CMAKE_LIBRARY_PREFIX}QtCore.${CMAKE_LIBRARY_SUFFIX}.5"
But I still don't think it's necessarily a good idea or the right change to
make. QMake and CMake don't necessarily agree on what the prefix and suffix
for libraries will be on different platforms for one thing.
What would you consider a good idea?
Could this have any implications for cross-compiling?
Currently I generate IMPORTED_CONFIGURATIONS for debug and release
(conditionally, depending on how Qt is built). Should I also generate code
to set target properties for no configuration? Or should I only do that, and
not have debug/release versions?:
set_target_properties(Qt5Core PROPERTIES
IMPORTED_LINK_INTERFACE_LIBRARIES ""
IMPORTED_LOCATION "${_qt5_install_prefix}/lib/libQtCore.so.5.0.0"
IMPORTED_SONAME"libQtCore.so.5"
)
Thanks for any guidance,
Steve.
--
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
Re: [cmake-developers] Generating imported library targets without the cmake executable
Stephen Kelly wrote: > > Hi there, > > I am working on installing CMake config files from the Qt repository so > that there is less need for a FindQt.cmake. By the way, it would be very helpful if anyone tried to build and test this on windows and mac. The clone is at https://qt.gitorious.org/+kdab-developers/qt/kdab-developers-qtbase/ the branch is cmake_files. The testing steps are: 1) build and install Qt 2) cd qtbase/tests/manual/cmake 3) mkdir build && cd build 4) cmake .. && make 5) No error reported == success. Thanks, Steve. -- 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
Re: [cmake-developers] Generating imported library targets without the cmake executable
Alexander Neundorf wrote: > On Friday 25 November 2011, Stephen Kelly wrote: >> Stephen Kelly wrote: >> > Hi there, >> > >> > I am working on installing CMake config files from the Qt repository so >> > that there is less need for a FindQt.cmake. >> >> By the way, it would be very helpful if anyone tried to build and test >> this on windows and mac. >> >> The clone is at >> >> https://qt.gitorious.org/+kdab-developers/qt/kdab-developers-qtbase/ >> >> the branch is cmake_files. The testing steps are: >> >> 1) build and install Qt >> 2) cd qtbase/tests/manual/cmake >> 3) mkdir build && cd build >> 4) cmake .. && make >> 5) No error reported == success. > > Could you maybe put the generated .cmake files somewhere ? > This would save hours in downloading, compiling etc. > I think you'll get more and quicker feedback then. I can't generate the files. I'm asking people with windows and mac setups to generate them and post them for review. I don't have those setups. I would hope it doesn't take hours to download and compile. In fact, you can stop after running ./configure and inspect the generated .cmake files. -- 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
Re: [cmake-developers] Generating imported library targets without the cmake executable
On 11/28/2011 05:51 PM, Brad King wrote: On 11/25/2011 10:02 AM, Stephen Kelly wrote: https://qt.gitorious.org/+kdab-developers/qt/kdab-developers-qtbase/ the branch is cmake_files. The testing steps are: 1) build and install Qt It doesn't appear to build at all on Windows with VS 9: Thanks for trying this. It could be that Qt requires VS10 on Windows. According to this page: http://developer.qt.nokia.com/wiki/Qt_5.0 If you have that available could you try with it? I had someone else trying to test the cmake stuff on windows (Qt built fine for him), but for some reason he was getting linker errors which I couldn't explain. It might need someone familiar with both CMake and windows to figure out. kdab-developers-qtbase\include\qtgui\../../src/gui/kernel/qwindowdefs.h(147) : error C2065: 'WId' : undeclared identifier The #if blocks above that error do have a case for Windows but it does not define WId. It looks like commit 401f0783 removed src/gui/kernel/qwindowdefs_win.h and then commit 66febd27 restored it but with that line missing. See: $ git diff 401f0783^:src/gui/kernel/qwindowdefs_win.h 66febd27:src/gui/kernel/qwindowdefs_win.h @@ -115,8 +115,6 @@ typedef long HRESULT; #endif typedef struct tagMSG MSG; -typedef HWND WId; - QT_BEGIN_NAMESPACE Restoring the line gets only slightly further and stops with NMAKE : fatal error U1073: don't know how to make 'image\qpixmap_win.cpp' -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
[cmake-developers] Windows build issues? (Was Re: Generating imported library targets without the cmake executable)
Hi, Is Qt supposed to be buildable with VS 10 on Windows? Context here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/2338/focus=2347 Thanks, Steve.--- Begin Message --- On 11/28/2011 11:57 AM, Stephen Kelly wrote: On 11/28/2011 05:51 PM, Brad King wrote: On 11/25/2011 10:02 AM, Stephen Kelly wrote: https://qt.gitorious.org/+kdab-developers/qt/kdab-developers-qtbase/ the branch is cmake_files. The testing steps are: 1) build and install Qt It doesn't appear to build at all on Windows with VS 9: Thanks for trying this. It could be that Qt requires VS10 on Windows. According to this page: http://developer.qt.nokia.com/wiki/Qt_5.0 If you have that available could you try with it? Same problem with VS 10 sp1. -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 --- End Message --- -- 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
[cmake-developers] Windows build issues? (Was Generating imported library targets without the cmake executable)
Hi, Is Visual Studio 10 the requirement for building Qt? Context here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/2338/focus=2347 Thanks, Steve. On Monday, November 28, 2011 13:28:04 Brad King wrote: > On 11/28/2011 11:57 AM, Stephen Kelly wrote: > > On 11/28/2011 05:51 PM, Brad King wrote: > >> On 11/25/2011 10:02 AM, Stephen Kelly wrote: > >>> https://qt.gitorious.org/+kdab-developers/qt/kdab-developers-qtbase/ > >>> > >>> the branch is cmake_files. The testing steps are: > >>> > >>> 1) build and install Qt > >> > >> It doesn't appear to build at all on Windows with VS 9: > > Thanks for trying this. It could be that Qt requires VS10 on Windows. > > According to this page: > > > > http://developer.qt.nokia.com/wiki/Qt_5.0 > > > > If you have that available could you try with it? > > Same problem with VS 10 sp1. > > -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-- 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
Re: [cmake-developers] target_include_directories branch in stage
Brad King writes:
>
> On 11/6/2011 5:45 PM, Stephen Kelly wrote:I'd prefer it to be though if
> > we can sort out the issues with what should be the target feature set.
>
> Good. We can work on this and revise/rewrite the topic there first and then
> merge to next for testing when the design is more mature.
>
I've been working on this topic again, but I forgot that I had not merged it
into next. I think I properly reverted it though.
> The INCLUDE_DIRECTORIES property of a target must be the *only* list
> from which the final include directory list is constructed. When a target
> is created the current directory-level include directories must be used
> to initialize the list. Further include_directories() calls in the same
> directory must append not only to the directory-level list but also to
> the property for all existing targets. At any intermediate point a
> target's property can be modified independently (see the set_property
> command example below).
This works for me locally now.
> Now we can return to per-config include directories. To incorporate them
> into the same single list, we will need some kind of markup on a per-entry
> basis. This is similar to the "debug/optimized" keywords used by the
> target_link_libraries command, but must be more well designed. Perhaps
> a syntax similar to generator expressions in custom commands can work.
> I'll have to think more about it.
I worked on the functionality for per-config target includes, but the syntax is
not right yet. For now it's:
set_property(TARGET foo APPEND PROPERTY INCLUDE_DIRECTORIES ${foo_INCLUDES})
set_property(TARGET foo APPEND PROPERTY INCLUDE_DIRECTORIES_DEBUG
${bar_INCLUDES})
get_property(VAR foo INCLUDE_DIRECTORIES_DEBUG) # VAR is Always empty
get_property(VAR foo INCLUDE_DIRECTORIES) # In Debug configuration, VAR is
# foo_INCLUDES and bar_INCLUDES. In non-Debug it's foo_INCLUDES only.
> > So before I merge this into next, I'm wondering if this feature can be
> > considered for inclusion in 2.8.7?
>
> Whatever features are mature and merged to master before the release will
> be in it. We won't hold up a release for this though.
At the moment, all CMake unit tests pass for me with the branch (and I've just
fixed the style), but I think not all generators are configured to build for me,
so they remain unported for now. Are special switches needed to build CodeBlocks
and Eclipse Generators?
At this point I'd like some guidance on whether the general approach I took is
the correct one, and where I should go from here. I'm not familiar with lots of
parts of CMake that I'm touching, and there are lots of classes whose
responsibility and interactions with the other classes is not clear to me
(GlobalGenerator, LocalGenerator, LocalUnixMakefileGenerator3 etc). cmMakefile
doesn't seem to represent a Makefile. Is the name historical?
Anyway, while information on those classes might be useful, eyes on the patch
and feedback on the approach would be more so. My approach so far has been to
attempt to remove the use of cmMakefile::GetIncludeDirectories from everywhere
except cmTarget (which uses it to initialize its own directories) and replace it
with calls to the target for the include directories.
Thanks,
Steve.
--
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
Re: [cmake-developers] Generating imported library targets without the cmake executable
Brad King wrote:
> On 11/29/2011 8:00 AM, Stephen Kelly wrote:
>> Alexander Neundorf wrote:
>>>> I can't generate the files. I'm asking people with windows and mac
>>>> setups to generate them and post them for review. I don't have those
>>>> setups.
>>>
>>> Just the ones for Linux would already help :-)
>>
>> I managed to get generated files for windows and mac through some IRC
>> puppeteering, so I've attached them here now.
>
> What is the purpose of conditions like
>
>if (NOT "debug" STREQUAL "")
>
> in the Config.cmake files?
The config files are created using the qmake QMAKE_SUBSTITUTES feature,
which is functionally similar to configure_file().
qmake knows whether it is building release or debug Qt libraries (or both as
on windows and mac), so that information is used in the .in file:
https://qt.gitorious.org/+kdab-developers/qt/kdab-developers-
qtbase/blobs/cmake_files/mkspecs/cmake/Qt5BasicConfig.cmake.in
if building debug libraries it sets the debug_type variable to anything non
empty ("debug", similar for release_type in the same file) and
if (NOT \"$${debug_type}\" STREQUAL \"\")
is generated to
if (NOT "debug" STREQUAL "")
Otherwise (if debug libraries are not built) it is generated as
if (NOT "" STREQUAL "")
The mac frameworks stuff etc is done in the same way, as is the windows .lib
stuff, so the same thing appears several files in the file.
I agree it's not very nice, but I couldn't find a better way to do it. qmake
doesn't have an equivalent to file(WRITE), which might otherwise be used for
the platform specific stuff.
Thanks,
Steve.
--
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
Re: [cmake-developers] Generating imported library targets without the cmake executable
Brad King wrote:
> On 11/29/2011 8:00 AM, Stephen Kelly wrote:
>> Alexander Neundorf wrote:
>>>> I can't generate the files. I'm asking people with windows and mac
>>>> setups to generate them and post them for review. I don't have those
>>>> setups.
>>>
>>> Just the ones for Linux would already help :-)
>>
>> I managed to get generated files for windows and mac through some IRC
>> puppeteering, so I've attached them here now.
>
> For these lines:
>
> set(Qt5Core_LIBRARY Qt5Core)
> set(Qt5Core_HEADER_DIR "${_qt5_install_prefix}/include" )
> set(Qt5Core_INCLUDE_DIRS "${Qt5Core_HEADER_DIR}"
> "${_qt5_install_prefix}/include/QtCore")
> set(Qt5Core_LIBRARY_DIR
> "${_qt5_install_prefix}/lib")
>
> What is the purpose of each variable? Usually singular names like
> FOO_LIBRARY and FOO_INCLUDE_DIR are used in find_*() commands to
> cache the results of specific searches. The results reported from
> a find or config module for use by the application use plural names
> like FOO_LIBRARIES and FOO_INCLUDE_DIRS and FOO_LIBRARY_DIRS.
Qt5Core_LIBRARY is intended to be the thing that users would use in the
CMakeLists.txt.
I've had another read of the Modules/readme.txt and I guess I need to change
it to be consistent.
So should I rename them or should I instead add
set(Qt5Core_LIBRARIES ${Qt5Core_LIBRARY})
etc for each variable?
Thanks,
Steve.
--
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
Re: [cmake-developers] Generating imported library targets without the cmake executable
Brad King wrote:
> On 11/29/2011 10:53 AM, Stephen Kelly wrote:
>> Qt5Core_LIBRARY is intended to be the thing that users would use in the
>> CMakeLists.txt.
>>
>> I've had another read of the Modules/readme.txt and I guess I need to
>> change it to be consistent.
>>
>> So should I rename them or should I instead add
>>
>> set(Qt5Core_LIBRARIES ${Qt5Core_LIBRARY})
>
> This convention is only used in Find modules to collect the individual
> find results. In the Config modules you already know the complete list
> so you can go straight to the plural name. So the minimum is:
>
>set(Qt5Core_LIBRARIES Qt5Core)
>set(Qt5Core_INCLUDE_DIRS "${_qt5_install_prefix}/include"
> "${_qt5_install_prefix}/include/QtCore")
>
> The library directory holding Qt5Core is not needed in
>
>set(Qt5Core_LIBRARY_DIRS "${_qt5_install_prefix}/lib") # not needed
>
> because the imported target know where to find the libraries. However,
> if there are dependencies on third-party libraries that are not loaded
> as imported targets or full paths then the locations of those belong
> in the above list.
Ok, I'll see about these modifications later or tomorrow.
>
> Is there a reason to provide
>
>set(Qt5Core_HEADER_DIR "${_qt5_install_prefix}/include" )
>
> at all?
>
I provide that because FindQt4.cmake provides QT_HEADER_DIR. I'm not sure
why it is provided by that find module.
Thanks,
Steve.
--
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
Re: [cmake-developers] Generating imported library targets without the cmake executable
Alexander Neundorf wrote: > On Tuesday 29 November 2011, Stephen Kelly wrote: >> Alexander Neundorf wrote: >> >> I can't generate the files. I'm asking people with windows and mac >> >> setups to generate them and post them for review. I don't have those >> >> setups. >> > >> > Just the ones for Linux would already help :-) >> >> I managed to get generated files for windows and mac through some IRC >> puppeteering, so I've attached them here now. >> >> Thanks, > > I looked through the QtCore files. > > Some things: > > if (NOT _Qt5Core_target) > set(_Qt5Core_target 1) > add_library(Qt5Core SHARED IMPORTED) > if (NOT "" STREQUAL "") > set_property(TARGET Qt5Core PROPERTY FRAMEWORK 1) > endif() > endif() > > I think you can simply do: > > if(NOT TARGET Qt5Core) > add_library(Qt5Core SHARED IMPORTED) > if (NOT "" STREQUAL "") > set_property(TARGET Qt5Core PROPERTY FRAMEWORK 1) > endif() > endif() I didn't do it like this because that could potentially hide errors as described here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/2147/focus=2152 Someone else could define a target called QtCore (in theory at least), and it makes sense to show a failure as early as possible. > > > Can this also handle already static builds of Qt ? Nope, not yet. Static builds of Qt are no longer tested by Nokia at least as far as I know. I don't know if it is even possible to build Qt statically on all (or any) platforms anymore. If it is possible, I'm sure I can generate suitable config files for that. > > Why do you have an if() around including Qt5CoreMacros.cmake and > Qt5CoreConfigExtras.cmake ? Not all Qt modules have a Macros file or a ConfigExtras file. Qt5Sql for example. I didn't want to check if the file exists at CMake time and only include() it then. I wanted to determine at QMake time whether it should be there or not. If it is not there (due to installation or packaging error etc), the include() will be called and will fail with an error message instead of being quietly not included. Thanks for the review. Steve. -- 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
Re: [cmake-developers] Generating imported library targets without the cmake executable
Alexander Neundorf wrote:
> On Tuesday 29 November 2011, Brad King wrote:
>> On 11/29/2011 10:53 AM, Stephen Kelly wrote:
>> > Qt5Core_LIBRARY is intended to be the thing that users would use in the
>> > CMakeLists.txt.
>> >
>> > I've had another read of the Modules/readme.txt and I guess I need to
>> > change it to be consistent.
>> >
>> > So should I rename them or should I instead add
>> >
>> > set(Qt5Core_LIBRARIES ${Qt5Core_LIBRARY})
>>
>> This convention is only used in Find modules to collect the individual
>> find results. In the Config modules you already know the complete list
>> so you can go straight to the plural name.
>
> Yes.
> Nevertheless, personally I would also provide the Qt5Core_LIBRARY
> variable, so if somebody wants to have a look what that variable currently
> actually is (would by the name if the imported target), he can do that,
> and then maybe do something with the target name.
> This is harder if there is only the plural version of the variables.
> I'd say those singular versions are not strictly necessary, but they don't
> hurt and can in some cases be useful.
If it's a cached variable, someone could potentially redefine QtCore_LIBRARY
to some other Qt on their system than the one listed in the config file. I
don't know if that's something that is intended to be supported, but I think
I've seen someone do things like that before.
It seems like if things like that should be supported, then both the
singular and plural forms should exist.
When there's agreement on whether both should exist I can patch the code.
Thanks,
Steve.
--
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
Re: [cmake-developers] cmake automoc breaks kde
Alexander Neundorf wrote: > On Tuesday 22 November 2011, Stephen Kelly wrote: >> On 11/22/2011 10:03 PM, Alexander Neundorf wrote: >> >> Now when I try to build the frameworks branch using the cmake next >> >> branch, I get: >> >> >> >> AUTOMOC: error: >> >> /home/stephen/dev/src/kf5/tier1/libkcoreaddons/src/io/kdirwatch.cpp: >> >> The file includes the moc file "kdirwatch_p.moc", which seems to be >> >> the moc file from a different source file. This is not supported. >> >> Include "kdirwatch.moc" to run moc on this source file. >> > >> > I added special handling now for the case that basename_p.moc is >> > included with Qt4. >> >> Your new commits work with the parts of the frameworks branch affected >> by this, yes. >> >> However, there are still many places where the foo.moc file is expected >> to be the result of moc'ing the header, which causes errors like this: >> >> >> In file included from >> /home/stephen/dev/build/qt48/kf5/tier1/libkdbus/kdbus_automoc.cpp:2:0: >> /home/stephen/dev/build/qt48/kf5/tier1/libkdbus/moc_kdbusinterprocesslock.c >> pp: In static member function 'static void >> KDBusInterProcessLock::qt_static_metacall(QObject*, QMetaObject::Call, >> int, void**)': >> /home/stephen/dev/build/qt48/kf5/tier1/libkdbus/moc_kdbusinterprocesslock.c >> pp:55:22: error: invalid use of incomplete type 'struct >> KDBusInterProcessLockPrivate' >> /home/stephen/dev/build/qt48/kf5/tier1/libkdbus/../../../../../src/kf5/tie >> r1/libkdbus/kdbusinterprocesslock.h:30:7: error: forward declaration of >> 'struct KDBusInterProcessLockPrivate' >> >> Fixed by changing the include from foo.moc to moc_foo.cpp of course. >> >> This is due to the use of Q_PRIVATE_SLOT. I've just added a testcase to >> the branch. > > Please give the current AutomocIncludedDotMocFileHandling branch a try, it > checks now also for this. Building solid still fails with the AutomocIncludedDotMocFileHandling branch. One of the reasons for failure is including a file with a different basename .moc. Fixed in solid with -#include "devicenotifier.moc" +#include "moc_devicenotifier.cpp" in devicemanager.cpp. The other failure is building files in subdirectories from a CMakeLists two levels up (all the files in the subdirectories are compiled into a single library) and including their moc files, which fails. /home/stephen/dev/src/kf5/tier1/solid/solid/backends/fakehw/fakedevice.cpp:338:42: fatal error: backends/fakehw/fakedevice.moc: No such file or directory Solid builds standalone with Qt 4 in the frameworks branch. You already have it in your kdelibs git repo. The easiest thing would be: git new-workdir kdelibs kdelibs-frameworks frameworks cd kdelibs-frameworks/tier1/solid mkdir build && cd build cmake .. && make For convenience I put the current solid source here: http://www.steveire.com/share/solid.tar.gz You can decide how much of this should be covered in the backwards guarantee automoc feature and how much will require fixing solid instead. I attach the patch which fixes solid with cmake AutomocIncludedDotMocFileHandling branch. Thanks, Steve. diff --git a/tier1/solid/solid/audiointerface.cpp b/tier1/solid/solid/audiointerface.cpp index ddf6cbc..98e42b2 100644 --- a/tier1/solid/solid/audiointerface.cpp +++ b/tier1/solid/solid/audiointerface.cpp @@ -67,4 +67,4 @@ Solid::AudioInterface::SoundcardType Solid::AudioInterface::soundcardType() cons return_SOLID_CALL(Ifaces::AudioInterface *, d->backendObject(), InternalSoundcard, soundcardType()); } -#include "audiointerface.moc" +#include "moc_audiointerface.cpp" diff --git a/tier1/solid/solid/backends/fakehw/fakedevice.cpp b/tier1/solid/solid/backends/fakehw/fakedevice.cpp index dce82e4..1e5781a 100644 --- a/tier1/solid/solid/backends/fakehw/fakedevice.cpp +++ b/tier1/solid/solid/backends/fakehw/fakedevice.cpp @@ -335,5 +335,5 @@ QObject *FakeDevice::createDeviceInterface(const Solid::DeviceInterface::Type &t return iface; } -#include "backends/fakehw/fakedevice.moc" +#include "backends/fakehw/moc_fakedevice.cpp" #include "backends/fakehw/fakedevice_p.moc" diff --git a/tier1/solid/solid/devicemanager.cpp b/tier1/solid/solid/devicemanager.cpp index 06919c3..0fd8c89 100644 --- a/tier1/solid/solid/devicemanager.cpp +++ b/tier1/solid/solid/devicemanager.cpp @@ -288,6 +288,6 @@ void Solid::DeviceManagerStorage::ensureManagerCreated() } } -#include "devicenotifier.moc" +#include "moc_devicenotifier.cpp" #include "moc_devicemanager_p.cpp" -- 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
Re: [cmake-developers] Generating imported library targets without the cmake executable
Brad King wrote: > On 11/29/2011 8:40 PM, Stephen Kelly wrote: >> Alexander Neundorf wrote: >>> Nevertheless, personally I would also provide the Qt5Core_LIBRARY >>> variable, so if somebody wants to have a look what that variable >>> currently actually is (would by the name if the imported target), he can >>> do that, and then maybe do something with the target name. >>> This is harder if there is only the plural version of the variables. >>> I'd say those singular versions are not strictly necessary, but they >>> don't hurt and can in some cases be useful. >> >> If it's a cached variable, someone could potentially redefine >> QtCore_LIBRARY > > Alex was proposing simply to provide the singular name as a variable but > not > to cache it. The only reason to cache a variable is when we're searching > and > need to let the user help out or override. In a Config.cmake file we know > the answer. Ok, so you're saying the user should definitely not be able to override the value, so it shouldn't be cached. The remaining question is whether it should be provided anyway uncached for the reasons Alex described. If that should be done, then I can do that. Thanks, Steve. -- 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
Re: [cmake-developers] Generating imported library targets without the cmake executable
Brad King wrote: > On 11/30/2011 9:09 AM, Stephen Kelly wrote: >> Brad King wrote: >>> Alex was proposing simply to provide the singular name as a variable but >>> not >>> to cache it. The only reason to cache a variable is when we're >>> searching and >>> need to let the user help out or override. In a Config.cmake file we >>> know the answer. >> >> Ok, so you're saying the user should definitely not be able to override >> the value, so it shouldn't be cached. The remaining question is whether >> it should be provided anyway uncached for the reasons Alex described. If >> that should be done, then I can do that. > > I don't mind providing it for convenience. However more variables means > more variables. Users may not know which one to use when. I don't have > a strong opinion either way. Ok, my opinion is to provide one variable in plural form for now. If there is a reason to provide a singular form, we can add that later. Let's just see what Alex and CLinton say before I do that. Thanks, Steve. -- 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
Re: [cmake-developers] cmake automoc breaks kde
Alexander Neundorf wrote: > Thanks. > > diff --git a/tier1/solid/solid/audiointerface.cpp > b/tier1/solid/solid/audiointerface.cpp > index ddf6cbc..98e42b2 100644 > --- a/tier1/solid/solid/audiointerface.cpp > +++ b/tier1/solid/solid/audiointerface.cpp > @@ -67,4 +67,4 @@ Solid::AudioInterface::SoundcardType > Solid::AudioInterface::soundcardType() cons > return_SOLID_CALL(Ifaces::AudioInterface *, d->backendObject(), > InternalSoundcard, soundcardType()); > } > > -#include "audiointerface.moc" > +#include "moc_audiointerface.cpp" > > An alternative way to fix this is to include in the header and > not include the moc file here at all. Personally I prefer fixing the moc include so that it's still possible to forward declare in the header file. It is very common to forward declare in KDE. I don't know how likely this is to occur though. However, including the correct include file is an easy fix. We can start the updating of the KDE moc strategy soon I think. You said that you can't detect this case, but why do you have to? Isn't there already a check for the Q_OBJECT macro in the cpp file? Wouldn't the logic be 'if the .moc file is included but there is no Q_OBJECT in the header, then moc the .h and put the result in .moc', or does that conflict with another rule? > > - > > > diff --git a/tier1/solid/solid/backends/fakehw/fakedevice.cpp > b/tier1/solid/solid/backends/fakehw/fakedevice.cpp > index dce82e4..1e5781a 100644 > --- a/tier1/solid/solid/backends/fakehw/fakedevice.cpp > +++ b/tier1/solid/solid/backends/fakehw/fakedevice.cpp > @@ -335,5 +335,5 @@ QObject *FakeDevice::createDeviceInterface(const > Solid::DeviceInterface::Type &t > return iface; > } > > -#include "backends/fakehw/fakedevice.moc" > +#include "backends/fakehw/moc_fakedevice.cpp" > #include "backends/fakehw/fakedevice_p.moc" > > > This one was actually a bug, this one works now with the updated branch. Cool. > > > - > > diff --git a/tier1/solid/solid/devicemanager.cpp > b/tier1/solid/solid/devicemanager.cpp > index 06919c3..0fd8c89 100644 > --- a/tier1/solid/solid/devicemanager.cpp > +++ b/tier1/solid/solid/devicemanager.cpp > @@ -288,6 +288,6 @@ void > Solid::DeviceManagerStorage::ensureManagerCreated() > } > } > > -#include "devicenotifier.moc" > +#include "moc_devicenotifier.cpp" > #include "moc_devicemanager_p.cpp" > > In this case at least the error message is early and to the point: > "AUTOMOC: error: /home/alex/src/CMake/tests/solid/solid/devicemanager.cpp: > The file includes the moc file "devicenotifier.moc", which seems to be the > moc file from a different source file. This is not supported. Include > "devicemanager.moc" to run moc on this source file." > > An alternative fix is the following: > > diff -rbup solid.orig/solid//solid/CMakeLists.txt > solid//solid/CMakeLists.txt > --- solid.orig/solid//solid/CMakeLists.txt 2011-11-23 > 11:32:15.0 +0100 > +++ solid//solid/CMakeLists.txt 2011-11-30 21:48:13.0 +0100 > @@ -42,6 +42,7 @@ set(solid_LIB_SRCS > managerbase.cpp > device.cpp > devicemanager.cpp > + devicenotifier.h > deviceinterface.cpp > genericinterface.cpp > processor.cpp Seems out of place there. Again I prefer the direct include, but good that there's multiple solutions. > > > diff -rbup solid.orig/solid//solid/devicemanager.cpp > solid//solid/devicemanager.cpp > --- solid.orig/solid//solid/devicemanager.cpp 2011-11-30 > 03:08:04.0 +0100 > +++ solid//solid/devicemanager.cpp 2011-11-30 21:49:17.0 > +0100 @@ -288,6 +288,5 @@ void Solid::DeviceManagerStorage::ensure > } > } > > -#include "devicenotifier.moc" > #include "moc_devicemanager_p.cpp" > > >> You can decide how much of this should be covered in the backwards >> guarantee automoc feature and how much will require fixing solid instead. > > Yes, I'm quite undecided. > The breakages above are caused by forward declarations in the header > (which I can't detect), and by moc'ing files which are not known to cmake > at all (devicenotifier.h, and there is no devicenotifier.cpp). > > So I think with the current cmQtAutomoc::ParseCpp() I can't handle and > can't detect and warn for those cases. Which would mean that automoc in > 2.8.7 will not be able to substitute the standalone automoc4 (as 2.8.6 > was). This is not really good. > But at least now in 2.8.7 automoc behaves more like what the documentation > said already in 2.8.6, so it could be argued that everything which was > working before is still working now and everything which does not work > anymore was working only by accident. > Which seems kind of ok, Yes, I think the situation is pretty good with it now, though we haven't tried to build the rest of KDE with it. > but this still means that even if we start to > require cmake 2.8.7 for kdelibs4, we still need the standalone automoc > (which I don't feel like main
Re: [cmake-developers] Generating imported library targets without the cmake executable
Stephen Kelly wrote: > Brad King wrote: > >> On 11/30/2011 9:09 AM, Stephen Kelly wrote: >>> Brad King wrote: >>>> Alex was proposing simply to provide the singular name as a variable >>>> but not >>>> to cache it. The only reason to cache a variable is when we're >>>> searching and >>>> need to let the user help out or override. In a Config.cmake file we >>>> know the answer. >>> >>> Ok, so you're saying the user should definitely not be able to override >>> the value, so it shouldn't be cached. The remaining question is whether >>> it should be provided anyway uncached for the reasons Alex described. If >>> that should be done, then I can do that. >> >> I don't mind providing it for convenience. However more variables means >> more variables. Users may not know which one to use when. I don't have >> a strong opinion either way. > > Ok, my opinion is to provide one variable in plural form for now. If there > is a reason to provide a singular form, we can add that later. Let's just > see what Alex and CLinton say before I do that. I've submitted patches now to remove unneeded variables, pluralize the remaining, and use Qt5::Core style for the targets. -- 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
Re: [cmake-developers] Generating imported library targets without the cmake executable
Alexander Neundorf wrote: >> >> Static builds of Qt are no longer tested by Nokia at least as far as I >> know. I don't know if it is even possible to build Qt statically on all >> (or any) platforms anymore. > > Ah, ok. > So if we (at work) would like to have static builds, we maybe should take > action ? > I would say now is a good time to see if you can build Qt the way you need to. Experimentally building your own project on top of the cmake stuff that is now in there should be possible. I've done it with grantlee and fixed a few bugs in Qt5 as a result, but I haven't tried any static builds. git clone git://gitorious.org/qt/qtbase.git -- 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
Re: [cmake-developers] cmake automoc breaks kde
Alexander Neundorf wrote: >> > but this still means that even if we start to >> > require cmake 2.8.7 for kdelibs4, we still need the standalone automoc >> > (which I don't feel like maintaining). >> >> Well, kdelibs4 is not really going to get any more releases. I'm not sure >> it makes sense to change the cmake requirement for it, but that's more a >> topic for kde-buildsystem. If you really meant frameworks branch, then >> I'd say we fix solid and move on. > > No, I meant kdelibs4. > Still people will continue to build against it for some time (it's not > even dead yet), and the cmake stuff in it should stay maintained. > This would be easier if there was only one group of files (the ones in > e-c-m), instead of two (kdelibs4 and e-c-m). > See the mail for the FindQtMobility.cmake review... I'll look into it. > > ... >> There are a great deal of warnings like: >> >> /home/stephen/dev/src/grantlee/templates/lib/template.cpp:0: Note: No >> relevant classes found. No output generated. >> >> because moc is run on the cpp file (it is also run on the header of >> course). >> >> Is it possible to give a better warning from cmake in those cases? If >> not, it's probably a big deal. > > "not a big deal", right ? Yes, sorry this was a typo. I meant not it's not a big deal if no better warning is possible. Thanks, Steve. -- 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
Re: [cmake-developers] target_include_directories branch in stage
Brad King wrote: > On 11/29/2011 7:34 AM, Stephen Kelly wrote: >> I've been working on this topic again, but I forgot that I had not merged >> it into next. I think I properly reverted it though. > > I added another commit to the revert-... branch to fully revert it. > To avoid accidental merges of work-in-progress topics, please instead > create a github.com account, visit > > https://github.com/Kitware/CMake > > and use the "Fork" button to get your own repo in which to publish topics. > Then post a link to the topics there for us to fetch and review. That way > you can rewrite the topic arbitrarily during development. Ok. I've pushed it to my gitorious repo for now. I'll remove the config stuff there and let you know when that's done. Should I push it to github too or is gitorious also ok when it's ready for review? Thanks, Steve. -- 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
Re: [cmake-developers] target_include_directories branch in stage
Brad King wrote: > On 12/1/2011 3:47 PM, Stephen Kelly wrote: >>> https://github.com/Kitware/CMake >>> >>> and use the "Fork" button >> >> Ok. I've pushed it to my gitorious repo for now. I'll remove the config >> stuff there and let you know when that's done. >> >> Should I push it to github too or is gitorious also ok when it's ready >> for review? > > Gitorious is fine. What is your URL? > git://gitorious.org/~steveire/cmake/steveires-cmake.git No useful update there yet though. Thanks, Steve. -- 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
Re: [cmake-developers] cmake automoc breaks kde
Alexander Neundorf wrote: >> You said that you can't detect this case, but why do you have to? Isn't >> there already a check for the Q_OBJECT macro in the cpp file? Wouldn't >> the logic be 'if the .moc file is included but there is no >> Q_OBJECT in the header, then moc the .h and put the result in >> .moc', or does that conflict with another rule? > > I'll put some more work in it over the weekend. > Probably something like this should work. > Or "if it's not my own .moc-file, never assume it's the .moc-file from > another cpp-file (end of story here with Qt5), but try whether it could be > the moc- file from a header". > Please make the behaviour difference not determined by Qt4 vs Qt5 but by a variable. That is, please make: find_package(Qt4) set(CMAKE_AUTOMOC ON) set(CMAKE_AUTOMOC_STRICT ON) behave with what you call the 'Qt5' behaviour, and find_package(QtCore 5) set(CMAKE_AUTOMOC ON) set(CMAKE_AUTOMOC_STRICT OFF) behave with what you call the 'Qt4' behaviour. That is, introduce a CMAKE_AUTOMOC_STRICT variable to control which mode the automoc stuff works with, and have a different default between Qt4 and Qt5, but allow overriding that default. Porting to Qt5 (for KDE at least) needs to eb a multi-step process for applications depending on kdelibs (and this feature). I think it needs to be possible to run automoc in non-strict mode with Qt5. Thanks, Steve. -- 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
Re: [cmake-developers] target_include_directories branch in stage
Brad King wrote: > On 11/29/2011 7:34 AM, Stephen Kelly wrote: >> I worked on the functionality for per-config target includes, but the >> syntax is not right yet. > > Please remove per-config support for now. Do you mean I should remove the UI feature of setting the INCLUDE_DIRECTORIES_DEBUG property adding to the include directories of the debug config, or do you additionally mean that I should remove the current implementation that keeps order and keeps the specified config. The current implementation (std::vector >) would work for the UI syntax you suggest below. It seems like removing the implementation detail only for it to be re-added later when the UI syntax is decided would be inefficient. I'm fine with removing the INCLUDE_DIRECTORIES_ UI feature. > With the approach I have in mind it will be a simple matter to add support > for it after the main feature works. I want to make the approach > something > general so it can be applied to other things like link directories. The > idea is to process the single list in the generator and look for special > syntax that indicates whether each entry is meant for the current config. > > I haven't settled on a syntax yet but it will be similar to generator > expressions from add_test and add_custom_command: > > $ > > This entry would be ignored if the CONFIG? condition doesn't match. The > cmGeneratorExpression class can be used to evaluate it. Ok. Is this something that should aim for post-2.8.7? Should I aim to get taget specific INCLUDE_DIRECTORIES into 2.8.7 (within this week) and aim for adding this config-specific feature later (would that be source compatible?). Thanks, Steve. -- 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
Re: [cmake-developers] target_include_directories branch in stage
David Cole wrote: > > I, for one, would really like to see per-target include directories in > 2.8.7, even without per-config support to start with. Then, add the > per-config support / new generator expressions in a later release. > That seems unlikely to happen. If RC1 is Wednesday, it would have to be clean on the dashboard by then, which means cleanup of issues reported by the nightlies on Tuesday, which means putting it in next on Monday in order to get the nightlies generated. I've pushed the branch to my gitorious clone again. https://gitorious.org/~steveire/cmake/steveires-cmake The top two commits need to be reviewed and have real fixes decided and written for them. Should the memoization be removed? What does cmMakeDepends do? Note that if the goal is to merge this into next on Monday, there is little point explaining this to me and asking me to make the necessary changes. That would be too inefficient. git reset HEAD^^ and doing the fixes would be better. Additionally, the generators for XCode and VisualStudio don't build in the branch (though I haven't tried) because I changed the signature of LocalGenerator::GetIncludeDirectories. Again, that would have to be fixed by someone with direct access to those platforms and/or generators. Finally, the Eclipse generator builds, and all tests pass, which means mostly that I don't know how to test it. I didn't port it away from cmMakefile::GetIncludeDirectories, and yet the (updated) IncludeDirectories test passes. I expected the test to fail. To run the test I did: mkdir eclipse_gen && cd eclipse_gen cmake .. -G "Eclipse CDT4 - Unix Makefiles" && make ./bin/ctest Again, asking me to fix these issues would be too inefficient because I don't have direct access to the platforms, am unfamiliar with what cmMakeDepend.cxx or the memoization should be doing, and don't know enough about the eclipse generator to fix it. All that would have to be done tomorrow in order to make the RC and I would not be able to make that happen. Given that this feedback didn't happen last week, people who can give it don't likely have time on Monday either. So the options are probably delay the RC (which wouldn't make me any more capable of fixing the remaining issues anyway. It would still need $Your help) or defer the feature. Thanks, Steve. -- 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
Re: [cmake-developers] target_include_directories branch in stage
Alexander Neundorf wrote:
> On Sunday 04 December 2011, Stephen Kelly wrote:
>> David Cole wrote:
>> > I, for one, would really like to see per-target include directories in
>> > 2.8.7, even without per-config support to start with. Then, add the
>> > per-config support / new generator expressions in a later release.
>>
>> That seems unlikely to happen. If RC1 is Wednesday, it would have to be
>> clean on the dashboard by then, which means cleanup of issues reported by
>> the nightlies on Tuesday, which means putting it in next on Monday in
>> order to get the nightlies generated.
>>
>> I've pushed the branch to my gitorious clone again.
>>
>> https://gitorious.org/~steveire/cmake/steveires-cmake
>>
>> The top two commits need to be reviewed and have real fixes decided and
>> written for them. Should the memoization be removed? What does
>> cmMakeDepends do? Note that if the goal is to merge this into next on
>> Monday, there is little point explaining this to me and asking me to make
>> the necessary changes. That would be too inefficient. git reset HEAD^^
>> and doing the fixes would be better.
>>
>> Additionally, the generators for XCode and VisualStudio don't build in
>> the branch (though I haven't tried) because I changed the signature of
>> LocalGenerator::GetIncludeDirectories. Again, that would have to be fixed
>> by someone with direct access to those platforms and/or generators.
>>
>> Finally, the Eclipse generator builds, and all tests pass, which means
>> mostly that I don't know how to test it. I didn't port it away from
>> cmMakefile::GetIncludeDirectories, and yet the (updated)
>> IncludeDirectories test passes. I expected the test to fail. To run the
>> test I did:
>>
>> mkdir eclipse_gen && cd eclipse_gen
>> cmake .. -G "Eclipse CDT4 - Unix Makefiles" && make
>> ./bin/ctest
>
> The Eclipse generator generates Makefiles, and additionally Eclipse
> project files. But those are not tested during the tests, only the
> makefiles are tested.
> I don't know of any way to test automatically whether an Eclipse project
> works (except loading it manually).
>
> What could be broken there ?
>
The IncludeDirectories test. The Eclipse generator calls
GetIncludeDirectories on the cmMakefile instead of asking the targets for
the include directories.
stephen@hal:~/dev/src/cmake{target-include-directories}$ git grep
GetIncludeDirec | grep Eclip
Source/cmExtraEclipseCDT4Generator.cxx: = (*it)->GetMakefile()-
>GetIncludeDirectories();
See the commit 'Extract and use the INCLUDE_DIRECTORIES target properties'
in the branch, in particular the change to
Source/cmLocalUnixMakefileGenerator3.cxx. Perhaps something similar is
needed in the eclipse generator.
Thanks,
Steve.
--
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
Re: [cmake-developers] A few more changes to automoc before 2.8.7
Alexander Neundorf wrote: >> And, again a question regarding wording, currently the warnings generated >> by automoc say "Better for a more robust build." >> I'd like to have a better way to express it. >> "Use for STRICT mode compatibility." ? >> or "for qmake compatibility" ? >> Better ideas ? > > I pushed it as branch AutomocFineTuning to stage. > The variable is now CMAKE_AUTOMOC_RELAXED_MODE . > > If that's fine with everybody, I'll merge it into next in the next days. > This should still go into 2.8.7. I applied the attached patch and kdelibs build fails using the AutomocFineTuning branch (as expected). Uncommenting the line to invert the relaxed mode makes it build again. I'm fine with the change. However, the warnings/errors output by cmake don't include a reference to CMAKE_AUTOMOC_RELAXED_MODE (as that is not referenced in all error/warning cases). Thanks, Steve. diff --git a/CMakeLists.txt b/CMakeLists.txt index ad97626..5654033 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -45,11 +45,12 @@ if (KHTML_BUILD_TESTREGRESSION) endif (KHTML_BUILD_TESTREGRESSION) option(STATIC_LIBRARY "Build kdelibs as static libraries." FALSE) +#set(CMAKE_AUTOMOC_RELAXED_MODE ON) add_subdirectory( libinqt5 ) add_subdirectory( libqtmimetypes ) add_subdirectory( tier1 ) - +return() # write platform profile file which will be installed # include(CreateKDEPlatformProfile.cmake) -- 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
Re: [cmake-developers] A few more changes to automoc before 2.8.7
Alexander Neundorf wrote: > On Thursday 15 December 2011, Stephen Kelly wrote: >> Alexander Neundorf wrote: >> >> And, again a question regarding wording, currently the warnings >> >> generated by automoc say "Better for a more robust >> >> build." I'd like to have a better way to express it. >> >> "Use for STRICT mode compatibility." ? >> >> or "for qmake compatibility" ? >> >> Better ideas ? >> > >> > I pushed it as branch AutomocFineTuning to stage. >> > The variable is now CMAKE_AUTOMOC_RELAXED_MODE . >> > >> > If that's fine with everybody, I'll merge it into next in the next >> > days. This should still go into 2.8.7. >> >> I applied the attached patch and kdelibs build fails using the >> AutomocFineTuning branch (as expected). > > You mean setting CMAKE_AUTOMOC_RELAXED_MODE to TRUE, right ? > Yes, that's expected. I mean not setting it at all and letting it take its default value of True. > >> Uncommenting the line to invert the relaxed mode makes it build again. >> I'm fine with the change. >> >> However, the warnings/errors output by cmake don't include a reference to >> CMAKE_AUTOMOC_RELAXED_MODE (as that is not referenced in all >> error/warning cases). > > Do you have commit e474dcb23197489640456b4 already ? > http://cmake.org/gitweb?p=stage/cmake.git;a=commit;h=e474dcb23197489640456b46862a5aa7019834a5 > > I committed this Wednesday evening and though I had inserted it in all > places where it makes sense. Yes, I have this commit already. It might make sense to put the message in the other places. Thanks, Steve. -- 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
Re: [cmake-developers] A few more changes to automoc before 2.8.7
Alexander Neundorf wrote: > On Friday 16 December 2011, Stephen Kelly wrote: >> Alexander Neundorf wrote: >> > On Thursday 15 December 2011, Stephen Kelly wrote: >> >> Alexander Neundorf wrote: >> >> >> And, again a question regarding wording, currently the warnings >> >> >> generated by automoc say "Better for a more >> >> >> robust build." I'd like to have a better way to express it. >> >> >> "Use for STRICT mode compatibility." ? >> >> >> or "for qmake compatibility" ? >> >> >> Better ideas ? >> >> > >> >> > I pushed it as branch AutomocFineTuning to stage. >> >> > The variable is now CMAKE_AUTOMOC_RELAXED_MODE . >> >> > >> >> > If that's fine with everybody, I'll merge it into next in the next >> >> > days. This should still go into 2.8.7. >> >> >> >> I applied the attached patch and kdelibs build fails using the >> >> AutomocFineTuning branch (as expected). >> > >> > You mean setting CMAKE_AUTOMOC_RELAXED_MODE to TRUE, right ? >> > Yes, that's expected. >> >> I mean not setting it at all and letting it take its default value of >> True. > > > Do you mean the relaxed mode should be default ? > Why ? In strict mode it behaves exactly as documented. > For KDE it shouldn't be a problemit's just that one variable which has to > be set. Ok, there was confusion introduced earlier in the thread. I let CMake take the default value of False (not true, as you wrote) for RELAXED_MODE, which is why it fails as expected. -- 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
Re: [cmake-developers] A few more changes to automoc before 2.8.7
Alexander Neundorf wrote: > On Sunday 18 December 2011, Alexander Neundorf wrote: >> On Friday 16 December 2011, Stephen Kelly wrote: >> > Alexander Neundorf wrote: >> > > On Thursday 15 December 2011, Stephen Kelly wrote: >> > >> Alexander Neundorf wrote: >> > >> >> And, again a question regarding wording, currently the warnings >> > >> >> generated by automoc say "Better for a more >> > >> >> robust build." I'd like to have a better way to express it. >> > >> >> "Use for STRICT mode compatibility." ? >> > >> >> or "for qmake compatibility" ? >> > >> >> Better ideas ? >> > >> > >> > >> > I pushed it as branch AutomocFineTuning to stage. >> > >> > The variable is now CMAKE_AUTOMOC_RELAXED_MODE . >> > >> > >> > >> > If that's fine with everybody, I'll merge it into next in the next >> > >> > days. This should still go into 2.8.7. >> > >> >> > >> I applied the attached patch and kdelibs build fails using the >> > >> AutomocFineTuning branch (as expected). >> > > >> > > You mean setting CMAKE_AUTOMOC_RELAXED_MODE to TRUE, right ? >> > > Yes, that's expected. >> > >> > I mean not setting it at all and letting it take its default value of >> > True. >> >> Do you mean the relaxed mode should be default ? >> Why ? In strict mode it behaves exactly as documented. >> For KDE it shouldn't be a problemit's just that one variable which has to >> be set. >> >> > >> Uncommenting the line to invert the relaxed mode makes it build >> > >> again. I'm fine with the change. >> > >> >> > >> However, the warnings/errors output by cmake don't include a >> > >> reference to CMAKE_AUTOMOC_RELAXED_MODE (as that is not referenced >> > >> in all error/warning cases). >> > > >> > > Do you have commit e474dcb23197489640456b4 already ? >> > >> > http://cmake.org/gitweb?p=stage/cmake.git;a=commit;h=e474dcb2319748964045 >> > 6b 46862a5aa7019834a5 >> > >> > > I committed this Wednesday evening and though I had inserted it in >> > > all places where it makes sense. >> > >> > Yes, I have this commit already. It might make sense to put the message >> > in the other places. >> >> I'll have a look. > > I had a look. Did you try a build? Even with the early return() so that it's done very quickly? > From my POV they look good as they are. > Where would you like to have additional mentions of > CMAKE_AUTOMOC_RELAXED_MODE, and what should they actually say ? I think it was about _p moc files. > (In strict mode I don't check for all the special conditions, so it is > currently not possible to reliably determine whether an error in strict > mode will be handled in relaxed mode). Thanks, Steve. -- 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
Re: [cmake-developers] A few more changes to automoc before 2.8.7
Alexander Neundorf wrote: > On Sunday 18 December 2011, Stephen Kelly wrote: >> Alexander Neundorf wrote: >> > On Sunday 18 December 2011, Alexander Neundorf wrote: >> >> On Friday 16 December 2011, Stephen Kelly wrote: >> >> > Alexander Neundorf wrote: >> >> > > On Thursday 15 December 2011, Stephen Kelly wrote: >> >> > >> Alexander Neundorf wrote: >> >> > >> >> And, again a question regarding wording, currently the >> >> > >> >> warnings generated by automoc say "Better >> >> > >> >> for a more robust build." I'd like to have a better way to >> >> > >> >> express it. "Use for STRICT mode >> >> > >> >> compatibility." ? or "for qmake compatibility" ? >> >> > >> >> Better ideas ? >> >> > >> > >> >> > >> > I pushed it as branch AutomocFineTuning to stage. >> >> > >> > The variable is now CMAKE_AUTOMOC_RELAXED_MODE . >> >> > >> > >> >> > >> > If that's fine with everybody, I'll merge it into next in the >> >> > >> > next days. This should still go into 2.8.7. >> >> > >> >> >> > >> I applied the attached patch and kdelibs build fails using the >> >> > >> AutomocFineTuning branch (as expected). >> >> > > >> >> > > You mean setting CMAKE_AUTOMOC_RELAXED_MODE to TRUE, right ? >> >> > > Yes, that's expected. >> >> > >> >> > I mean not setting it at all and letting it take its default value >> >> > of True. >> >> >> >> Do you mean the relaxed mode should be default ? >> >> Why ? In strict mode it behaves exactly as documented. >> >> For KDE it shouldn't be a problemit's just that one variable which has >> >> to be set. >> >> >> >> > >> Uncommenting the line to invert the relaxed mode makes it build >> >> > >> again. I'm fine with the change. >> >> > >> >> >> > >> However, the warnings/errors output by cmake don't include a >> >> > >> reference to CMAKE_AUTOMOC_RELAXED_MODE (as that is not >> >> > >> referenced in all error/warning cases). >> >> > > >> >> > > Do you have commit e474dcb23197489640456b4 already ? >> >> http://cmake.org/gitweb?p=stage/cmake.git;a=commit;h=e474dcb2319748964045 >> >> >> > 6b 46862a5aa7019834a5 >> >> > >> >> > > I committed this Wednesday evening and though I had inserted it in >> >> > > all places where it makes sense. >> >> > >> >> > Yes, I have this commit already. It might make sense to put the >> >> > message in the other places. >> >> >> >> I'll have a look. >> > >> > I had a look. >> >> Did you try a build? Even with the early return() so that it's done very >> quickly? >> >> > From my POV they look good as they are. >> > Where would you like to have additional mentions of >> > CMAKE_AUTOMOC_RELAXED_MODE, and what should they actually say ? >> >> I think it was about _p moc files. > > "Scanning dependencies of target solid_automoc > [ 0%] Automoc for target solid > AUTOMOC: error: > /home/alex/src/CMake/tests/solid.orig/solid/solid/device.cpp: The file > includes the moc file "device_p.moc", which seems to be the moc file from > a different source file. This is not supported. Include "device.moc" to > run moc on this source file." > > Looks good IMO for strict mode. > How would you like to have that changed ? I expected this to also have a message about CMAKE_AUTOMOC_RELAXED_MODE. If it was intentional not to add the note, then it's probably ok. Thanks, Steve. -- 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
Re: [cmake-developers] [CMake 0012645]: In GenerateExportHeader.cmake IS_ABSOLUTE is used with a variable name instead of a path
Mantis Bug Tracker wrote: > > The following issue has been SUBMITTED. > == > http://cmake.org/Bug/view.php?id=12645 > == > Reported By:Michael Wild > Assigned To: Just chiming in to say thanks for the fix. :) -- 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
Re: [cmake-developers] target_include_directories branch in stage
On 12/05/2011 03:17 PM, Brad King wrote:
On 12/4/2011 12:49 PM, Stephen Kelly wrote:
I've pushed the branch to my gitorious clone again.
https://gitorious.org/~steveire/cmake/steveires-cmake
Hi,
I'm revisiting this now that CMake 2.8.7 is out.
I've force pushed my branch:
https://gitorious.org/~steveire/cmake/steveires-cmake/commits/target-include-directories
For context, the branch as it was on December 4th is preserved here:
https://gitorious.org/~steveire/cmake/steveires-cmake/commits/target-include-directories-old
Thanks. Why do you maintain a special std::vector member
to hold the INCLUDE_DIRECTORIES target property?
Mostly to simplify the implementation so that I don't need to serialize
and de-serialize in multiple places. I also figured it must be faster to
serialize and deserialize over const char * all the time in the multiple
places that is needed.
I think the property
can be stored just like any other property during configuration. Then
the generators can use ExpandListArguments.
Would that mean that every generator would have to ensure that the
includes were unique etc?
Initialization from the
directory property value can just be added to cmTarget::SetMakefile:
this->SetPropertyDefault("INCLUDE_DIRECTORIES", 0);
I tried this (also removing this->IncludeDirectories = makefileIncludes;
from the same function), and it makes the tests fail. This doesn't
surprise me, as as far as I knew and read from the code,
SetPropertyDefault is for initializing a property with the content of
the property with the same name with a "CMAKE_" prefix.
If I've understood what you meant here, please expand.
The directory-level IncludeDirectories vector can probably also go
away in favor of a normal directory property if things are properly
refactored.
The top two commits need to be reviewed and have real fixes decided and
written for them. Should the memoization be removed?
I have removed the last two commits from the branch and added a separate
commit to remove the memoization.
Once again, the tests all pass for me. However, I have only tested with
the "Unix Makefile" generator. The other generators (eg for Windows,
Mac?) likely do not work.
How can this feature now be moved forward? Do I need to convince someone
to volunteer to port the other generators? Should I just file a bug for
porting the other generators and wait (possibly making the feature bitrot)?
Thanks,
Steve.
--
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
[cmake-developers] Should a module attempt to find its own dependencies?
Hi, I don't think I've ever seen a direct answer to this question. Is it something to be decided on a case by case basis? If so, then why is there no general case? I can see a possible reason that it is not solvable in the general case because sometimes the behaviour of find_package can be changed by setting variables (eg, one might use QT_USE_QTXMLPATTERNS before finding Qt4). Specifically this comes up for me because I need to know whether Qt5 modules should find their own dependencies. That is, should find_package(Qt5Gui) cause find_package(Qt5Core REQUIRED) to be called or not? Should that be the responsibility of the caller? Thanks, Steve. -- 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
Re: [cmake-developers] Should a module attempt to find its own dependencies?
Alexander Neundorf wrote:
> On Sunday 08 January 2012, Stephen Kelly wrote:
>> Hi,
>>
>> I don't think I've ever seen a direct answer to this question.
>
> AFAIK, yes, they should.
> FindKDE4Internal.cmake finds Qt, FindPNG.cmake finds zlib.
>
>
>> Is it something to be decided on a case by case basis? If so, then why is
>> there no general case?
>>
>> I can see a possible reason that it is not solvable in the general case
>> because sometimes the behaviour of find_package can be changed by setting
>> variables (eg, one might use QT_USE_QTXMLPATTERNS before finding Qt4).
>>
>> Specifically this comes up for me because I need to know whether Qt5
>> modules should find their own dependencies. That is, should
>>
>> find_package(Qt5Gui)
>>
>> cause
>>
>> find_package(Qt5Core REQUIRED)
>>
>> to be called or not?
>
> I'd say yes.
> Otherwise the imported targets in Qt5Gui will depend on not yet defined
> targets from Qt5Core.
>
> The same way cmake takes care of adding the required additional libraries
> to the link line (like adding zlib when linking libpng), it should also
> take care of this, IMO.
>
> You should just have to state
> find_package(Foo)
> and this will get you Foo.
That implies that
* Qt5Gui_INCLUDE_DIRS should also contain Qt5Core_INCLUDE_DIRS
* Qt5Gui_DEFINITIONS should contain Qt5Core_DEFINITIONS
* Qt5Gui_COMPILE_DEFINITIONS should contain Qt5Core_COMPILE_DEFINITIONS
Right?
(for the libraries, the dependencies are already part of the link
dependencies variable).
Otherwise you would be doing this:
find_package(Foo)
include_directories(
${Foo_INCLUDE_DIRS}
${Bar_INCLUDE_DIRS} # Where does this come from ??
)
Thanks,
Steve.
--
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
Re: [cmake-developers] target_include_directories branch in stage
David Cole wrote: >> How can this feature now be moved forward? Do I need to convince someone > to volunteer to port the other generators? Should I just file a bug for > porting the other generators and wait (possibly making the feature > bitrot)? >> > > I volunteer to make sure this branch works with Xcode and Visual Studio. > I'll get to it within the next week... > Fantastic. It's definitely something that should be done as early in the cycle as possible. Just ask if you have any questions etc. Thanks, Steve. -- 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
Re: [cmake-developers] target_include_directories branch in stage
Just replying to say I'm not ignoring this message, but I won't have time to
work on it this week :).
Thanks,
Steve.
Brad King wrote:
> On 1/8/2012 11:47 AM, Stephen Kelly wrote:
>> On 12/05/2011 03:17 PM, Brad King wrote:
> >> I think the property
> >> can be stored just like any other property during configuration. Then
> >> the generators can use ExpandListArguments.
> >
> > Would that mean that every generator would have to ensure that the
> > includes were unique etc?
>
> Yes but there could be an internal API provided by cmTarget to compute the
> expansion in one place for use by any generator. I really think that all
> property values should be handled in the same way and interpreted in their
> non-string format only as needed.
>
>>> Initialization from the
>>> directory property value can just be added to cmTarget::SetMakefile:
>>>
>>> this->SetPropertyDefault("INCLUDE_DIRECTORIES", 0);
>>
>> SetPropertyDefault is for initializing a property with the content of the
> > property with the same name with a "CMAKE_" prefix.
>
> Sorry, my bad. You're right, except that it looks for a *variable* with
> the
> CMAKE_ prefix. Instead you can just spell out initialization of the
> target property by copying the current value of the directory property.
>
> -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
--
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
Re: [cmake-developers] target_include_directories branch in stage
Hi,
I've force pushed my branch:
https://gitorious.org/~steveire/cmake/steveires-cmake/commits/target-
include-directories
Brad King wrote:
> On 1/8/2012 11:47 AM, Stephen Kelly wrote:
>> On 12/05/2011 03:17 PM, Brad King wrote:
> >> I think the property
> >> can be stored just like any other property during configuration. Then
> >> the generators can use ExpandListArguments.
> >
> > Would that mean that every generator would have to ensure that the
> > includes were unique etc?
>
> Yes but there could be an internal API provided by cmTarget to compute the
> expansion in one place for use by any generator. I really think that all
> property values should be handled in the same way and interpreted in their
> non-string format only as needed.
Done.
>
>>> Initialization from the
>>> directory property value can just be added to cmTarget::SetMakefile:
>>>
>>> this->SetPropertyDefault("INCLUDE_DIRECTORIES", 0);
>>
>> SetPropertyDefault is for initializing a property with the content of the
> > property with the same name with a "CMAKE_" prefix.
>
> Sorry, my bad. You're right, except that it looks for a *variable* with
> the
> CMAKE_ prefix. Instead you can just spell out initialization of the
> target property by copying the current value of the directory property.
Ported.
I think the branch is ready for review again.
Thanks,
Steve.
--
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
