From eric.noulard at gmail.com Mon Jul 3 08:28:31 2017 From: eric.noulard at gmail.com (Eric Noulard) Date: Mon, 3 Jul 2017 14:28:31 +0200 Subject: [cmake-developers] Adding a new henerator for CMake In-Reply-To: References: Message-ID: Hi Renato, Did you start to work on a Bazel generator for CMake? If not do you still plan to do it? Eric 2017-03-17 11:51 GMT+01:00 Renato Utsch : > Ooh good to know, I'll take a look at how you're doing that. > > No, the build system is Bazel. > > On Fri, Mar 17, 2017, 04:58 Charles Huet wrote: > >> Hi, >> >> >> is this buildsystem by any chance FastBuild ? >> Because if so there is an effort (I'd like to say ongoing, but it's been >> on hold since the release of 9.7) to implement one here: >> https://github.com/packadal/CMake/tree/fastbuild-master >> >> Otherwise I guess it can serve as another example, as far as I know there >> is no documentation on how to implement a generator from scratch. >> >> Good luck ! >> >> Le ven. 17 mars 2017 ? 02:39, Renato Utsch a >> ?crit : >> >> Hello, >> >> Is there documentation somewhere on how to add a new generator to CMake? >> There's a build system I really want CMake to support, and I'd like to >> contribute to make that happen. >> >> How difficult / how much code is involved in writing a new generator? The >> build system has nothing to do with makefiles. >> >> Thank. >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at http://www.kitware.com/ >> opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake-developers >> >> > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake-developers > -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From renatoutsch at gmail.com Mon Jul 3 08:39:23 2017 From: renatoutsch at gmail.com (Renato Utsch) Date: Mon, 03 Jul 2017 12:39:23 +0000 Subject: [cmake-developers] Adding a new henerator for CMake In-Reply-To: References: Message-ID: Hi Eric, I was very interested in this but I unfortunately didn't have the time and probably won't have much time to work on this for the next year or so. Are you going to start working on this? Renato On Mon, Jul 3, 2017, 09:28 Eric Noulard wrote: > Hi Renato, > > Did you start to work on a Bazel generator for CMake? > If not do you still plan to do it? > > Eric > > 2017-03-17 11:51 GMT+01:00 Renato Utsch : > >> Ooh good to know, I'll take a look at how you're doing that. >> >> No, the build system is Bazel. >> >> On Fri, Mar 17, 2017, 04:58 Charles Huet wrote: >> >>> Hi, >>> >>> >>> is this buildsystem by any chance FastBuild ? >>> Because if so there is an effort (I'd like to say ongoing, but it's been >>> on hold since the release of 9.7) to implement one here: >>> https://github.com/packadal/CMake/tree/fastbuild-master >>> >>> Otherwise I guess it can serve as another example, as far as I know >>> there is no documentation on how to implement a generator from scratch. >>> >>> Good luck ! >>> >>> Le ven. 17 mars 2017 ? 02:39, Renato Utsch a >>> ?crit : >>> >>> Hello, >>> >>> Is there documentation somewhere on how to add a new generator to CMake? >>> There's a build system I really want CMake to support, and I'd like to >>> contribute to make that happen. >>> >>> How difficult / how much code is involved in writing a new generator? >>> The build system has nothing to do with makefiles. >>> >>> Thank. >>> >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: >>> http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For more >>> information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/cmake-developers >>> >>> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake-developers >> > > > > -- > Eric > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Mon Jul 3 08:48:24 2017 From: eric.noulard at gmail.com (Eric Noulard) Date: Mon, 3 Jul 2017 14:48:24 +0200 Subject: [cmake-developers] Adding a new henerator for CMake In-Reply-To: References: Message-ID: I was secretly hoping someone will do it :-) . No currently no plan to do it myself. I currently does not have enough time for that kind of task and my current knowledge of bazel is low... So no, at least not in short-/mid-term. Eric 2017-07-03 14:39 GMT+02:00 Renato Utsch : > Hi Eric, > > I was very interested in this but I unfortunately didn't have the time and > probably won't have much time to work on this for the next year or so. > > Are you going to start working on this? > > Renato > > On Mon, Jul 3, 2017, 09:28 Eric Noulard wrote: > >> Hi Renato, >> >> Did you start to work on a Bazel generator for CMake? >> If not do you still plan to do it? >> >> Eric >> >> 2017-03-17 11:51 GMT+01:00 Renato Utsch : >> >>> Ooh good to know, I'll take a look at how you're doing that. >>> >>> No, the build system is Bazel. >>> >>> On Fri, Mar 17, 2017, 04:58 Charles Huet wrote: >>> >>>> Hi, >>>> >>>> >>>> is this buildsystem by any chance FastBuild ? >>>> Because if so there is an effort (I'd like to say ongoing, but it's >>>> been on hold since the release of 9.7) to implement one here: >>>> https://github.com/packadal/CMake/tree/fastbuild-master >>>> >>>> Otherwise I guess it can serve as another example, as far as I know >>>> there is no documentation on how to implement a generator from scratch. >>>> >>>> Good luck ! >>>> >>>> Le ven. 17 mars 2017 ? 02:39, Renato Utsch a >>>> ?crit : >>>> >>>> Hello, >>>> >>>> Is there documentation somewhere on how to add a new generator to >>>> CMake? There's a build system I really want CMake to support, and I'd like >>>> to contribute to make that happen. >>>> >>>> How difficult / how much code is involved in writing a new generator? >>>> The build system has nothing to do with makefiles. >>>> >>>> Thank. >>>> >>>> -- >>>> >>>> Powered by www.kitware.com >>>> >>>> Please keep messages on-topic and check the CMake FAQ at: >>>> http://www.cmake.org/Wiki/CMake_FAQ >>>> >>>> Kitware offers various services to support the CMake community. For >>>> more information on each offering, please visit: >>>> >>>> CMake Support: http://cmake.org/cmake/help/support.html >>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>>> >>>> Visit other Kitware open-source projects at http://www.kitware.com/ >>>> opensource/opensource.html >>>> >>>> Follow this link to subscribe/unsubscribe: >>>> http://public.kitware.com/mailman/listinfo/cmake-developers >>>> >>>> >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: >>> http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For more >>> information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware open-source projects at http://www.kitware.com/ >>> opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/cmake-developers >>> >> >> >> >> -- >> Eric >> > -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From renatoutsch at gmail.com Mon Jul 3 10:38:25 2017 From: renatoutsch at gmail.com (Renato Utsch) Date: Mon, 03 Jul 2017 14:38:25 +0000 Subject: [cmake-developers] Adding a new henerator for CMake In-Reply-To: References: Message-ID: I was hoping that too haha Maybe next year I'll have time to work on that. Renato Em seg, 3 de jul de 2017 ?s 09:48, Eric Noulard escreveu: > I was secretly hoping someone will do it :-) > . > No currently no plan to do it myself. > I currently does not have enough time for that kind of task and my current > knowledge of bazel is low... > So no, at least not in short-/mid-term. > > Eric > > 2017-07-03 14:39 GMT+02:00 Renato Utsch : > >> Hi Eric, >> >> I was very interested in this but I unfortunately didn't have the time >> and probably won't have much time to work on this for the next year or so. >> >> Are you going to start working on this? >> >> Renato >> >> On Mon, Jul 3, 2017, 09:28 Eric Noulard wrote: >> >>> Hi Renato, >>> >>> Did you start to work on a Bazel generator for CMake? >>> If not do you still plan to do it? >>> >>> Eric >>> >>> 2017-03-17 11:51 GMT+01:00 Renato Utsch : >>> >>>> Ooh good to know, I'll take a look at how you're doing that. >>>> >>>> No, the build system is Bazel. >>>> >>>> On Fri, Mar 17, 2017, 04:58 Charles Huet >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> >>>>> is this buildsystem by any chance FastBuild ? >>>>> Because if so there is an effort (I'd like to say ongoing, but it's >>>>> been on hold since the release of 9.7) to implement one here: >>>>> https://github.com/packadal/CMake/tree/fastbuild-master >>>>> >>>>> Otherwise I guess it can serve as another example, as far as I know >>>>> there is no documentation on how to implement a generator from scratch. >>>>> >>>>> Good luck ! >>>>> >>>>> Le ven. 17 mars 2017 ? 02:39, Renato Utsch a >>>>> ?crit : >>>>> >>>>> Hello, >>>>> >>>>> Is there documentation somewhere on how to add a new generator to >>>>> CMake? There's a build system I really want CMake to support, and I'd like >>>>> to contribute to make that happen. >>>>> >>>>> How difficult / how much code is involved in writing a new generator? >>>>> The build system has nothing to do with makefiles. >>>>> >>>>> Thank. >>>>> >>>>> -- >>>>> >>>>> Powered by www.kitware.com >>>>> >>>>> Please keep messages on-topic and check the CMake FAQ at: >>>>> http://www.cmake.org/Wiki/CMake_FAQ >>>>> >>>>> Kitware offers various services to support the CMake community. For >>>>> more information on each offering, please visit: >>>>> >>>>> CMake Support: http://cmake.org/cmake/help/support.html >>>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>>>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>>>> >>>>> Visit other Kitware open-source projects at >>>>> http://www.kitware.com/opensource/opensource.html >>>>> >>>>> Follow this link to subscribe/unsubscribe: >>>>> http://public.kitware.com/mailman/listinfo/cmake-developers >>>>> >>>>> >>>> -- >>>> >>>> Powered by www.kitware.com >>>> >>>> Please keep messages on-topic and check the CMake FAQ at: >>>> http://www.cmake.org/Wiki/CMake_FAQ >>>> >>>> Kitware offers various services to support the CMake community. For >>>> more information on each offering, please visit: >>>> >>>> CMake Support: http://cmake.org/cmake/help/support.html >>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>>> >>>> Visit other Kitware open-source projects at >>>> http://www.kitware.com/opensource/opensource.html >>>> >>>> Follow this link to subscribe/unsubscribe: >>>> http://public.kitware.com/mailman/listinfo/cmake-developers >>>> >>> >>> >>> >>> -- >>> Eric >>> >> > > > -- > Eric > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcdailey.lists at gmail.com Wed Jul 5 09:10:49 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Wed, 5 Jul 2017 08:10:49 -0500 Subject: [cmake-developers] Built-in tag support for FindDoxygen In-Reply-To: References: Message-ID: I ran into an interesting situation. Originally, I had based documentation on real targets. And in some ways, I still do, but not directly anymore. I have some targets that are conditionally only built on certain platforms. However, I wanted documentation for that target to be generated regardless of platform. That means I cannot bind a doxygen target to its real target, since it may not be there. Everything else functions the same, and doxygen targets still build a "mirror" of the dependency tree of the real targets amongst themselves. Also the tag file generation happens the same way. What I'd like to do is maybe put my doxygen CMake code (that simply wraps doxygen_add_docs()) on a Gist for now or something, along with some usage examples, and see what you think as far as implementation goes. From there we can decide what needs to be integrated, or if maybe this is a separate function provided by FindDoxygen.cmake. I'll follow up later. Thanks for your advice. On Fri, Jun 30, 2017 at 9:48 PM, Craig Scott wrote: > > > On Thu, Jun 29, 2017 at 11:14 AM, Robert Dailey > wrote: >> >> Doxygen supports linking external documentation together: >> https://www.stack.nl/~dimitri/doxygen/manual/external.html >> >> Using doxygen_add_docs(), it doesn't provide built-in support for tag >> files. I'm thinking this would be beneficial since the way the >> function is designed encourages modular documentation. At least, I >> have my projects structured like this (targets): >> >> A >> A_doxygen >> B >> B_doxygen >> C >> C_doxygen >> >> I have 1 doxygen target per real library target. And each library has >> dependencies on others. When library C uses something from A, I want >> C_doxygen to link to the tagfile generated by A_doxygen. >> >> At the moment I'm accomplishing this by adding a target property to >> each real target to keep track of target dependencies. Example: >> >> add_library(C ...) >> target_link_libraries(C A) >> set_property(TARGET C PROPERTY TARGET_DEPENDENCIES A) >> >> When I'm building A_doxygen target (using doxygen_add_docs()), I >> specify DOXYGEN_GENERATE_TAGFILE. Then in C_doxygen, I specify >> DOXYGEN_TAGFILES to point to the one output by A_doxygen. >> >> I don't like keeping target properties to query the dependency tree, >> but this is the best I could come up with. Is there value in >> incorporating this into FindDoxygen.cmake? If so, I'd like to >> contribute it, if it's useful. > > > I think there's good potential for this idea. The doxygen_add_docs() > function could record the value of the DOXYGEN_GENERATE_TAGFILE variable in > a target property (I'd recommend using the same name as the variable). A new > DEPENDS option could be added to doxygen_add_docs() which would specify > other targets this one depends on. This would invoke add_dependencies() to > fulfil build ordering as usual, but it could also inspect the target > properties of the dependees and if the DOXYGEN_GENERATE_TAGFILE property is > set, then the DOXYGEN_TAGFILES variable could be augmented to pick up that > tag file somehow. You'd have to be careful how the paths were handled to > ensure they worked robustly, but conceptually at least I think this might be > possible and useful. Example usage would then be something like this: > > # Populate DOXYGEN_GENERATE_TAGFILE if not already set, > # use existing contents otherwise. Either way, define a target property > # on foo which records the value. > doxygen_add_docs(foo) > > # Does a similar thing as above for this target, but also picks up the > # tag file from foo as recorded in its target properties and augments > > # the DOXYGEN_TAGFILES variable as appropriate. > > doxygen_add_docs(bar DEPENDS foo) > > > You would need to be careful with how to handle contents of > DOXYGEN_GENERATE_TAGFILE and DOXYGEN_TAGFILES that the project might already > set. As a conservative measure, you might want to consider adding an option > NO_AUTO_TAGFILES or similar to disable any of this logic in case a project > does something complex and doxygen_add_docs() needs to be told to leave it > completely up to the project to handle. The doxygen_add_docs() function was > originally added with the intention of making it as easy as possible for > projects to use Doxygen with minimal extra configuration, so I think having > the auto tag handling enabled by default would probably be the right call, > as long as there's a way for projects to disable it if needed. > > > -- > Craig Scott > Melbourne, Australia > https://crascit.com From comicfans44 at gmail.com Wed Jul 5 19:29:10 2017 From: comicfans44 at gmail.com (comic fans) Date: Wed, 5 Jul 2017 19:29:10 -0400 Subject: [cmake-developers] can ctest script using CMAKE_CFG_INTDIR ? Message-ID: I'm running cmake tests on a experimental multi-config fastbuild generator, for test 106 TargetName: it has a custom command COMMAND ${CMAKE_COMMAND} -E copy ${CMAKE_CURRENT_SOURCE_DIR}/hello_world ${CMAKE_CURRENT_BINARY_DIR} and in test it compare two files: --test-command ${CMAKE_CMAKE_COMMAND} -E compare_files ${CMake_SOURCE_DIR}/Tests/TargetName/scripts/hello_world ${CMake_BINARY_DIR}/Tests/TargetName/scripts/hello_world) to avoid different config build overwrite output to each other,(fastbuild is strict and do not allow duplicate output) I tried to modify copy command as COMMAND ${CMAKE_COMMAND} -E copy ${CMAKE_CURRENT_SOURCE_DIR}/hello_world ${CMAKE_CURRENT_BINARY_DIR}/${CMAKE_CFG_INTDIR}/ now build successfully and files copied into different dir, but when I changed test script as : --test-command ${CMAKE_CMAKE_COMMAND} -E compare_files ${CMake_SOURCE_DIR}/Tests/TargetName/scripts/hello_world ${CMake_BINARY_DIR}/Tests/TargetName/scripts/${CMAKE_CFG_INTDIR}/hello_world) the test script will run as: /home/comicfans/working/CMake/fastbuild/bin/Release/ctest "--build-and-test" "/home/comicfans/working/CMake/Tests/TargetName" "/home/comicfans/working/CMake/fastbuild/Tests/TargetName" "--build-two-config" "--build-generator" "Fastbuild" "--build-project" "TargetName" "--build-options" "-DCMAKE_MAKE_PROGRAM:FILEPATH=/home/comicfans/working/fastbuild/tmp/x64Linux-Debug/Tools/FBuild/FBuildApp/fbuild" "--test-command" "/home/comicfans/working/CMake/fastbuild/bin/cmake" "-E" "compare_files" "/home/comicfans/working/CMake/Tests/TargetName/scripts/hello_world" "/home/comicfans/working/CMake/fastbuild/Tests/TargetName/scripts/FASTBUILD_DOLLAR_TAGConfigNameFASTBUILD_DOLLAR_TAG/hello_world" FASTBUILD_DOLLAR_TAGConfigNameFASTBUILD_DOLLAR_TAG is the place holder string of generator's GetCMakeCFGIntDir returned. so seems this variable didn't expand with build config, I wonder if this is problem of generator code(forgot to expand it in some places) , or CMAKE_CFG_INTDIR variable just didn't expanded during ctest ? and how can I makes this test script fits multi-config generator? From yannsuisini at gmail.com Thu Jul 6 08:28:03 2017 From: yannsuisini at gmail.com (yann suisini) Date: Thu, 6 Jul 2017 14:28:03 +0200 Subject: [cmake-developers] Keil ARMCC toolchain file seems broken Message-ID: Hi, I'm trying to use the existing armcc toolchain module, but I get a strange behaviour. when using it with cmak GUI , at the configure time I get : The C compiler identification is GNU 4.9.2 The CXX compiler identification is GNU 4.9.2 Check for working C compiler: D:/Dev/Dev-Cpp/MinGW64/bin/gcc.exe Check for working C compiler: D:/Dev/Dev-Cpp/MinGW64/bin/gcc.exe -- works Detecting C compiler ABI info Detecting C compiler ABI info - done Detecting C compile features Detecting C compile features - done Check for working CXX compiler: D:/Dev/Dev-Cpp/MinGW64/bin/c++.exe Check for working CXX compiler: D:/Dev/Dev-Cpp/MinGW64/bin/c++.exe -- works Detecting CXX compiler ABI info Detecting CXX compiler ABI info - done Detecting CXX compile features Detecting CXX compile features - done Configuring done Which is completely wrong , since Cmake detects and uses MinGW Oo -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Thu Jul 6 08:45:59 2017 From: brad.king at kitware.com (Brad King) Date: Thu, 6 Jul 2017 08:45:59 -0400 Subject: [cmake-developers] can ctest script using CMAKE_CFG_INTDIR ? In-Reply-To: References: Message-ID: On 07/05/2017 07:29 PM, comic fans wrote: > but when I changed test script as : > --test-command ${CMAKE_CMAKE_COMMAND} -E compare_files > ${CMake_SOURCE_DIR}/Tests/TargetName/scripts/hello_world > ${CMake_BINARY_DIR}/Tests/TargetName/scripts/${CMAKE_CFG_INTDIR}/hello_world) CMAKE_CFG_INTDIR expands to a placeholder that the native build tool will expand to the configuration chosen at build time. It can only be used in contexts that will be evaluated by the native build tool. There are other means of referring to the configuration during testing. By "ctest script" do you mean "ctest -S somescript.cmake", "CTestTestfile.cmake", or something else? -Brad From rcdailey.lists at gmail.com Thu Jul 6 11:21:42 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Thu, 6 Jul 2017 10:21:42 -0500 Subject: [cmake-developers] add_custom_target(): When is VERBATIM appropriate? Message-ID: This is a continuation of the discussion I had with Brad here: https://gitlab.kitware.com/cmake/cmake/merge_requests/1019#note_286609 Hopefully we can continue the discussion here, but I'm happy to hear from others as well. It was stated that VERBATIM is not necessarily useful in all cases. Are these cases documented anywhere? Basically, how would I decide when to use it and when not? For the MR above, it was suggested that it be used for paths related to FindDoxygen.cmake, but I'm not sure why it was recommended other than "Improved escaping behavior". Thanks in advance for any information to help clarify my confusion. From rcdailey.lists at gmail.com Fri Jul 7 14:13:04 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Fri, 7 Jul 2017 13:13:04 -0500 Subject: [cmake-developers] FindDoxygen is doing find_package() when it is included Message-ID: When I do this: message( "blah1" ) include( FindDoxygen ) message( "blah2" ) find_package( Doxygen 1.8.6 OPTIONAL_COMPONENTS dot ) message( "blah3" ) I get this output: blah1 -- Found Doxygen: C:/Program Files/doxygen/bin/doxygen.exe (found version "1.8.13") found components: doxygen missing components: dot blah2 -- Found Doxygen: C:/Program Files/doxygen/bin/doxygen.exe (found suitable version "1.8.13", minimum required is "1.8.6") found components: doxygen missing components: dot blah3 Two questions: 1. Why is find_package() happening automatically when I include the find module? This is contrary to the behavior of other find modules. I do not want it to find doxygen for me, as I have some minimum version requirements and I do not want it to find dot. How can I disable this implied search behavior? 2. Each time I run my scripts, it keeps searching for doxygen. Even though I've specified dot as an optional component. I do not want it to keep searching for doxygen each time I generate. It should find it once and be done. How can I fix this behavior? From rcdailey.lists at gmail.com Fri Jul 7 14:20:49 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Fri, 7 Jul 2017 13:20:49 -0500 Subject: [cmake-developers] FindDoxygen is doing find_package() when it is included In-Reply-To: References: Message-ID: I actually confused myself a bit... I think the issue is not that finding happens when including it, but that doxygen_add_docs() is bundled with the find module. What is the intended usage of this? If I do find_package() will that also make doxygen_add_docs() available? Or do I have to explicitly include FindDoxygen to get access to the function? On Fri, Jul 7, 2017 at 1:13 PM, Robert Dailey wrote: > When I do this: > > > message( "blah1" ) > include( FindDoxygen ) > > message( "blah2" ) > find_package( Doxygen 1.8.6 OPTIONAL_COMPONENTS dot ) > message( "blah3" ) > > > I get this output: > > > blah1 > -- Found Doxygen: C:/Program Files/doxygen/bin/doxygen.exe (found > version "1.8.13") found components: doxygen missing components: dot > blah2 > -- Found Doxygen: C:/Program Files/doxygen/bin/doxygen.exe (found > suitable version "1.8.13", minimum required is "1.8.6") found > components: doxygen missing components: dot > blah3 > > > Two questions: > > 1. Why is find_package() happening automatically when I include the > find module? This is contrary to the behavior of other find modules. I > do not want it to find doxygen for me, as I have some minimum version > requirements and I do not want it to find dot. How can I disable this > implied search behavior? > > 2. Each time I run my scripts, it keeps searching for doxygen. Even > though I've specified dot as an optional component. I do not want it > to keep searching for doxygen each time I generate. It should find it > once and be done. How can I fix this behavior? From rcdailey.lists at gmail.com Fri Jul 7 14:28:15 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Fri, 7 Jul 2017 13:28:15 -0500 Subject: [cmake-developers] FindDoxygen is doing find_package() when it is included In-Reply-To: References: Message-ID: Apologies for the confusion and spam: I figured out that when you do a find_package(), it also implicitly includes the contents of that module into your list file so you can access its functions. I was under the impression I had to include FindDoxygen.cmake explicitly to access the functions it provides. I'm guessing this is supported behavior. If so, I'll rely on it. On Fri, Jul 7, 2017 at 1:20 PM, Robert Dailey wrote: > I actually confused myself a bit... I think the issue is not that > finding happens when including it, but that doxygen_add_docs() is > bundled with the find module. What is the intended usage of this? If I > do find_package() will that also make doxygen_add_docs() available? Or > do I have to explicitly include FindDoxygen to get access to the > function? > > On Fri, Jul 7, 2017 at 1:13 PM, Robert Dailey wrote: >> When I do this: >> >> >> message( "blah1" ) >> include( FindDoxygen ) >> >> message( "blah2" ) >> find_package( Doxygen 1.8.6 OPTIONAL_COMPONENTS dot ) >> message( "blah3" ) >> >> >> I get this output: >> >> >> blah1 >> -- Found Doxygen: C:/Program Files/doxygen/bin/doxygen.exe (found >> version "1.8.13") found components: doxygen missing components: dot >> blah2 >> -- Found Doxygen: C:/Program Files/doxygen/bin/doxygen.exe (found >> suitable version "1.8.13", minimum required is "1.8.6") found >> components: doxygen missing components: dot >> blah3 >> >> >> Two questions: >> >> 1. Why is find_package() happening automatically when I include the >> find module? This is contrary to the behavior of other find modules. I >> do not want it to find doxygen for me, as I have some minimum version >> requirements and I do not want it to find dot. How can I disable this >> implied search behavior? >> >> 2. Each time I run my scripts, it keeps searching for doxygen. Even >> though I've specified dot as an optional component. I do not want it >> to keep searching for doxygen each time I generate. It should find it >> once and be done. How can I fix this behavior? From craig.scott at crascit.com Sun Jul 9 06:52:20 2017 From: craig.scott at crascit.com (Craig Scott) Date: Sun, 9 Jul 2017 20:52:20 +1000 Subject: [cmake-developers] ExternalProject documentation Message-ID: Devs, I've just put up a merge request that gives the ExternalProject documentation a bit of a makeover. It's a pretty complicated module and I'd appreciate a few sets of eyes, particularly from those who have had plenty of experience using that module. I'm still a little shaky on whether I've accurately presented the handling of step targets, so comments around that would be especially welcome. https://gitlab.kitware.com/cmake/cmake/merge_requests/1037 Cheers -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcdailey.lists at gmail.com Tue Jul 11 15:29:13 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Tue, 11 Jul 2017 14:29:13 -0500 Subject: [cmake-developers] 3.9.0-rc3: CMAKE_ANDROID_NDK_DEPRECATED_HEADERS doesn't work outside of toolchain In-Reply-To: <4fe38c6e-6d78-ab03-97bb-f1773bdcf76b@kitware.com> References: <6d16a99f-1850-a432-b6d4-3a87e7a4056f@kitware.com> <4fe38c6e-6d78-ab03-97bb-f1773bdcf76b@kitware.com> Message-ID: Just wanted to share my solution to this, based on your suggestions about code sharing. I still do some introspection but some of this is based on our usage of environment variables and such. However the logic to find NDK version is useful in general. Instead of pasting the CMake code here, I have made it available as a gist: https://gist.github.com/rcdailey/ae336b48b8681897c747524a5713c6c6 Hope this helps others that have similar questions. Thanks again Brad. On Tue, Jun 27, 2017 at 11:07 AM, Brad King wrote: > On 06/27/2017 11:36 AM, Robert Dailey wrote: >> Ok maybe I'm misunderstanding the design intent for toolchain files. > > Originally they were intended to contain information local to the > machine, like `set(CMAKE_ANDROID_NDK /path/on/my/machine/to/ndk)`. > In controlled environments that share many things it makes sense > to have deployable toolchain files instead. > >> Basically, some things I like to determine programmatically. Putting >> in them in the toolchain file violates the "introspection" rule, but >> also results in code duplication > > Toolchain files can `include()` other files from next to them. That > can be used to avoid duplicate code. > > The only information you need within your toolchain file logic to > compute CMAKE_ANDROID_NDK_DEPRECATED_HEADERS is CMAKE_ANDROID_NDK. > If you add logic to find/require CMAKE_ANDROID_NDK up front then you > can check its version. > > CMake's `Modules/Platform/Android-Determine.cmake` file has very little > logic to choose `CMAKE_ANDROID_NDK` if it is not set by the user. You > can either duplicate this in a toolchain file helper or take advantage > of knowledge about your controlled environments to have a shorter version. > > -Brad > From rcdailey.lists at gmail.com Tue Jul 11 18:55:25 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Tue, 11 Jul 2017 17:55:25 -0500 Subject: [cmake-developers] There's several issues with NDK support in CMake 3.9.0 Message-ID: So I'm working with DanAlbert over on the NDK github project regarding some issues I've hit with NDK r15b using CMake 3.9.0-rc5. He's already identified one bug that I can help fix located in `Modules/Platform/Android/ndk-stl-c++.cmake` related to platform support. He also mentions something a bit more serious regarding libandroid_support, which CMake isn't linking to. He recommended using their pre-packaged toolchain file that comes with the NDK itself. There's a couple more issues, I recommend heading over to the issue page and read up on the discussion there: https://github.com/android-ndk/ndk/issues/452 I'm stuck a bit in the middle here. I'm willing to help make changes and help with testing on the CMake side, but I'm not very knowledgeable on these things (compiler behavior, and CMake integration with NDK). What I'm hoping is that you guys can help pitch in on the discussion over on the NDK github page via the link above. I'll try to learn from the discussions there and contribute one or more merge requests to implement fixes. All of these issues cropped up from my specific usage of CMake with the NDK, so I'm in a really good position to be able to contribute fixes and test solutions. Just let me know how I can help. From rjvbertin at gmail.com Wed Jul 12 07:35:21 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Wed, 12 Jul 2017 13:35:21 +0200 Subject: [cmake-developers] FindPNG.cmake doesn't return a LIBRARY_DIR variable Message-ID: <2555015.gigOroPMWN@bola> Hi, I routinely use cmake to build projects for installation into a prefix (/opt/local) and that use libraries from that location which also exist in the system locations (typically in older versions, in that case). I thus have .pc files under /opt/local which generate linker instructions of the type "-L/opt/local/lib -lfoo". You'd expect this should work, but (too) often I still get linker errors about symbols not being found which upon verification are in fact provided by the intended library. In that case the -L/opt/local/lib is typically given only once on the linker command line ("way" before the corresponding -l argument), or not at all. See the example below, where I don't see the -L option at all (linker output and data from CMakeCache.txt after the HUGE linker command). Initially I thought this was a case where one shouldn't filter out identical -L options because the linker could limit their scope to just the -l option immediately following the -L, but in this case it appears that FindPNG.cmake simply doesn't consider the possibility that libpng might be found in a location that isn't in the standard library search path. IOW, FindPNG.cmake doesn't return a PNG_LIBRARY_DIR variable, and provides the full path only in an obsolete variable (PNG_LIBRARY). And for some reason, the command `target_link_libraries(digikamcore ... ${PNG_LIBRARIES} ...)` is translated into `-lpng -lz` . Is that a bug or feature? cd /path/todigikam/work/build/core/app && /opt/local/bin/cmake -E cmake_link_script CMakeFiles/digikamcore.dir/link.txt --verbose=1 /opt/local/bin/clang++-mp-4.0 -fPIC -O3 -g -DNDEBUG -std=c++11 -m64 -std=c++0x -Wno-gnu-zero-variadic-macro-arguments -Wall -Wextra -Wcast-align -Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith -Wundef -Wnon-virtual-dtor -Woverloaded-virtual -Werror=return-type -Wvla -Wdate-time -std=c++0x -fno-operator-names -Wno-gnu-zero-variadic-macro-arguments -Wall -Wextra -Wcast-align -Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith -Wundef -Wnon-virtual-dtor -Woverloaded-virtual -Werror=return-type -Wvla -Wdate-time -std=c++0x -fno-operator-names -Wno-gnu-zero-variadic-macro-arguments -Wall -Wextra -Wcast-align -Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith -Wundef -Wnon-virtual-dtor -Woverloaded-virtual -Werror=return-type -Wvla -Wdate-time -fexceptions -UQT_NO_EXCEPTIONS -Wl,--no-undefined -Wl,--fatal-warnings -Wl,--enable-new-dtags -Wl,--no-undefined -Wl,--fatal-warnings -Wl,--enable-new-dtags -Wl,--no-undefined -Wl,--fatal-warnings -Wl,--enable-new-dtags -Wl,-R,/opt/local/lib -shared -Wl,-soname,libdigikamcore.so.5.6.0 -o libdigikamcore.so.5.6.0 CMakeFiles/digikamcore.dir/utils/digikam_debug.cpp.o CMakeFiles/digikamcore.dir/digikamcore_autogen/moc_compilation.cpp.o ../libs/database/CMakeFiles/digikamdatabasecore_src.dir/server/databaseserverstarter.cpp.o ../libs/database/CMakeFiles/digikamdatabasecore_src.dir/server/databaseservererror.cpp.o ../libs/database/CMakeFiles/digikamdatabasecore_src.dir/server/databaseserver.cpp.o ../libs/database/CMakeFiles/digikamdatabasecore_src.dir/engine/dbengineconfigloader.cpp.o ../libs/database/CMakeFiles/digikamdatabasecore_src.dir/engine/dbengineconfig.cpp.o ../libs/database/CMakeFiles/digikamdatabasecore_src.dir/engine/dbengineactiontype.cpp.o ../libs/database/CMakeFiles/digikamdatabasecore_src.dir/engine/dbengineerrorhandler.cpp.o ../libs/database/CMakeFiles/digikamdatabasecore_src.dir/engine/dbengineguierrorhandler.cpp.o ../libs/database/CMakeFiles/digikamdatabasecore_src.dir/engine/dbengineparameters.cpp.o ../libs/database/CMakeFiles/digikamdatabasecore_src.dir/engine/dbenginebackend.cpp.o ../libs/database/CMakeFiles/digikamdatabasecore_src.dir/engine/dbenginesqlquery.cpp.o ../libs/database/CMakeFiles/digikamdatabasecore_src.dir/engine/dbengineaccess.cpp.o ../libs/database/CMakeFiles/digikamdatabasecore_src.dir/tags/tagregion.cpp.o ../libs/database/CMakeFiles/digikamdatabasecore_src.dir/thumbsdb/thumbsdb.cpp.o ../libs/database/CMakeFiles/digikamdatabasecore_src.dir/thumbsdb/thumbsdbchemaupdater.cpp.o ../libs/database/CMakeFiles/digikamdatabasecore_src.dir/thumbsdb/thumbsdbbackend.cpp.o ../libs/database/CMakeFiles/digikamdatabasecore_src.dir/thumbsdb/thumbsdbaccess.cpp.o ../libs/database/CMakeFiles/digikamdatabasecore_src.dir/digikamdatabasecore_src_autogen/moc_compilation.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/loaders/dimgloader.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/loaders/pngloader.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/loaders/jpegloader.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/loaders/tiffloader.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/loaders/rawloader.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/loaders/ppmloader.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/loaders/qimageloader.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/loaders/pgfloader.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/loaders/jpegsettings.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/loaders/pngsettings.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/loaders/tiffsettings.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/loaders/pgfsettings.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/loaders/jp2kloader.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/loaders/jp2ksettings.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/dklcms/digikam-lcms.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/dimgbuiltinfilter.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/dimgthreadedfilter.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/dimgthreadedanalyser.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/dimgfiltermanager.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/dimgfiltergenerator.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/filteractionfilter.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/randomnumbergenerator.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/rawprocessingfilter.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/decorate/borderfilter.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/decorate/bordersettings.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/decorate/texturefilter.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/film/filmfilter.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/fx/blurfilter.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/fx/blurfxfilter.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/fx/colorfxfilter.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/fx/colorfxsettings.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/fx/distortionfxfilter.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/fx/charcoalfilter.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/fx/embossfilter.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/fx/filmgrainfilter.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/fx/filmgrainsettings.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/fx/invertfilter.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/fx/pixelsaliasfilter.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/fx/oilpaintfilter.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/fx/raindropfilter.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/auto/autolevelsfilter.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/auto/autoexpofilter.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/auto/equalizefilter.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/auto/stretchfilter.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/auto/normalizefilter.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/cb/cbfilter.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/cb/cbsettings.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/bcg/bcgfilter.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/bcg/bcgsettings.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/bw/bwsepiafilter.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/bw/bwsepiasettings.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/bw/tonalityfilter.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/bw/infraredfilter.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/bw/mixerfilter.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/bw/mixersettings.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/hsl/hslfilter.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/hsl/hslsettings.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/hsl/hspreviewwidget.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/icc/iccmanager.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/icc/iccprofile.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/icc/iccprofilesettings.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/icc/icctransform.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/icc/icctransformfilter.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/icc/iccsettingscontainer.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/icc/iccsettings.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/lc/localcontrastfilter.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/lc/localcontrastsettings.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/lc/localcontrastcontainer.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/nr/nrfilter.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/nr/nrestimate.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/nr/nrsettings.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/sharp/sharpenfilter.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/sharp/unsharpmaskfilter.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/sharp/sharpsettings.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/levels/imagelevels.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/levels/levelsfilter.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/levels/imagehistogram.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/levels/histogrambox.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/levels/histogramwidget.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/levels/histogrampainter.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/curves/curvescontainer.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/curves/imagecurves.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/curves/curvesfilter.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/curves/curvessettings.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/curves/curveswidget.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/curves/curvesbox.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/wb/wbcontainer.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/wb/wbfilter.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/wb/wbsettings.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/transform/freerotationfilter.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/transform/freerotationsettings.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/transform/shearfilter.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/transform/autocrop.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/greycstoration/greycstorationfilter.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/greycstoration/greycstorationsettings.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/lens/antivignettingfilter.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/lens/antivignettingsettings.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/lens/lensdistortionfilter.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/lens/pixelaccess.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/redeye/redeyecorrectionfilter.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/redeye/redeyecorrectionsettings.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/redeye/redeyecorrectioncontainer.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/transform/contentawarefilter.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/lens/lensfunfilter.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/lens/lensfuncameraselector.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/lens/lensfuniface.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/lens/lensfunsettings.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/sharp/refocusfilter.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/filters/sharp/matrix.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/dimg.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/drawdecoding.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/dimgscale.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/dcolor.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/dcolorcomposer.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/imagehistory/dimagehistory.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/imagehistory/filteraction.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/imagehistory/historyimageid.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/dimg_src_autogen/moc_compilation.cpp.o ../libs/dmetadata/CMakeFiles/dmetadata_src.dir/metaengine.cpp.o ../libs/dmetadata/CMakeFiles/dmetadata_src.dir/metaengine_p.cpp.o ../libs/dmetadata/CMakeFiles/dmetadata_src.dir/metaengine_data.cpp.o ../libs/dmetadata/CMakeFiles/dmetadata_src.dir/metaengine_image.cpp.o ../libs/dmetadata/CMakeFiles/dmetadata_src.dir/metaengine_comments.cpp.o ../libs/dmetadata/CMakeFiles/dmetadata_src.dir/metaengine_exif.cpp.o ../libs/dmetadata/CMakeFiles/dmetadata_src.dir/metaengine_iptc.cpp.o ../libs/dmetadata/CMakeFiles/dmetadata_src.dir/metaengine_gps.cpp.o ../libs/dmetadata/CMakeFiles/dmetadata_src.dir/metaengine_xmp.cpp.o ../libs/dmetadata/CMakeFiles/dmetadata_src.dir/metaengine_previews.cpp.o ../libs/dmetadata/CMakeFiles/dmetadata_src.dir/metaengine_rotation.cpp.o ../libs/dmetadata/CMakeFiles/dmetadata_src.dir/dmetadata.cpp.o ../libs/dmetadata/CMakeFiles/dmetadata_src.dir/dmetadatasettings.cpp.o ../libs/dmetadata/CMakeFiles/dmetadata_src.dir/dmetadatasettingscontainer.cpp.o ../libs/dmetadata/CMakeFiles/dmetadata_src.dir/metadatasettings.cpp.o ../libs/dmetadata/CMakeFiles/dmetadata_src.dir/metadatasettingscontainer.cpp.o ../libs/dmetadata/CMakeFiles/dmetadata_src.dir/metadatainfo.cpp.o ../libs/dmetadata/CMakeFiles/dmetadata_src.dir/infocontainer.cpp.o ../libs/dmetadata/CMakeFiles/dmetadata_src.dir/geodetictools.cpp.o ../libs/dmetadata/CMakeFiles/dmetadata_src.dir/template.cpp.o ../libs/dmetadata/CMakeFiles/dmetadata_src.dir/captionvalues.cpp.o ../libs/dmetadata/CMakeFiles/dmetadata_src.dir/dmetadata_src_autogen/moc_compilation.cpp.o ../libs/jpegutils/CMakeFiles/jpegutils_src.dir/jpegutils.cpp.o ../libs/jpegutils/CMakeFiles/jpegutils_src.dir/iccjpeg.c.o ../libs/jpegutils/CMakeFiles/jpegutils_src.dir/libjpeg-84/transupp.c.o ../libs/jpegutils/CMakeFiles/jpegutils_src.dir/jpegutils_src_autogen/moc_compilation.cpp.o ../libs/progressmanager/CMakeFiles/progressmanager_src.dir/dhistoryview.cpp.o ../libs/progressmanager/CMakeFiles/progressmanager_src.dir/dprogresswdg.cpp.o ../libs/progressmanager/CMakeFiles/progressmanager_src.dir/overlaywidget.cpp.o ../libs/progressmanager/CMakeFiles/progressmanager_src.dir/progressview.cpp.o ../libs/progressmanager/CMakeFiles/progressmanager_src.dir/progressmanager.cpp.o ../libs/progressmanager/CMakeFiles/progressmanager_src.dir/statusbarprogresswidget.cpp.o ../libs/progressmanager/CMakeFiles/progressmanager_src.dir/statusprogressbar.cpp.o ../libs/progressmanager/CMakeFiles/progressmanager_src.dir/workingwidget.cpp.o ../libs/progressmanager/CMakeFiles/progressmanager_src.dir/dworkingpixmap.cpp.o ../libs/progressmanager/CMakeFiles/progressmanager_src.dir/progressmanager_src_autogen/moc_compilation.cpp.o ../libs/threadimageio/CMakeFiles/threadimageio_src.dir/dfileoperations.cpp.o ../libs/threadimageio/CMakeFiles/threadimageio_src.dir/filereadwritelock.cpp.o ../libs/threadimageio/CMakeFiles/threadimageio_src.dir/loadsavethread.cpp.o ../libs/threadimageio/CMakeFiles/threadimageio_src.dir/managedloadsavethread.cpp.o ../libs/threadimageio/CMakeFiles/threadimageio_src.dir/sharedloadsavethread.cpp.o ../libs/threadimageio/CMakeFiles/threadimageio_src.dir/loadingdescription.cpp.o ../libs/threadimageio/CMakeFiles/threadimageio_src.dir/loadingcache.cpp.o ../libs/threadimageio/CMakeFiles/threadimageio_src.dir/loadingcacheinterface.cpp.o ../libs/threadimageio/CMakeFiles/threadimageio_src.dir/loadsavetask.cpp.o ../libs/threadimageio/CMakeFiles/threadimageio_src.dir/previewloadthread.cpp.o ../libs/threadimageio/CMakeFiles/threadimageio_src.dir/previewtask.cpp.o ../libs/threadimageio/CMakeFiles/threadimageio_src.dir/previewsettings.cpp.o ../libs/threadimageio/CMakeFiles/threadimageio_src.dir/thumbnailbasic.cpp.o ../libs/threadimageio/CMakeFiles/threadimageio_src.dir/thumbnailcreator.cpp.o ../libs/threadimageio/CMakeFiles/threadimageio_src.dir/thumbnailloadthread.cpp.o ../libs/threadimageio/CMakeFiles/threadimageio_src.dir/thumbnailtask.cpp.o ../libs/threadimageio/CMakeFiles/threadimageio_src.dir/thumbnailsize.cpp.o ../libs/threadimageio/CMakeFiles/threadimageio_src.dir/videothumbnailer.cpp.o ../libs/threadimageio/CMakeFiles/threadimageio_src.dir/videothumbnailerjob.cpp.o ../libs/threadimageio/CMakeFiles/threadimageio_src.dir/threadimageio_src_autogen/moc_compilation.cpp.o ../libs/pgfutils/CMakeFiles/pgfutils_src.dir/pgfutils.cpp.o ../libs/pgfutils/CMakeFiles/pgfutils_src.dir/Decoder.cpp.o ../libs/pgfutils/CMakeFiles/pgfutils_src.dir/Encoder.cpp.o ../libs/pgfutils/CMakeFiles/pgfutils_src.dir/PGFimage.cpp.o ../libs/pgfutils/CMakeFiles/pgfutils_src.dir/PGFstream.cpp.o ../libs/pgfutils/CMakeFiles/pgfutils_src.dir/Subband.cpp.o ../libs/pgfutils/CMakeFiles/pgfutils_src.dir/WaveletTransform.cpp.o ../libs/pgfutils/CMakeFiles/pgfutils_src.dir/pgfutils_src_autogen/moc_compilation.cpp.o ../libs/threads/CMakeFiles/dthread_src.dir/actionthreadbase.cpp.o ../libs/threads/CMakeFiles/dthread_src.dir/threadmanager.cpp.o ../libs/threads/CMakeFiles/dthread_src.dir/workerobject.cpp.o ../libs/threads/CMakeFiles/dthread_src.dir/dynamicthread.cpp.o ../libs/threads/CMakeFiles/dthread_src.dir/parallelworkers.cpp.o ../libs/threads/CMakeFiles/dthread_src.dir/dthread_src_autogen/moc_compilation.cpp.o ../libs/versionmanager/CMakeFiles/versionmanager_src.dir/versionmanager.cpp.o ../libs/versionmanager/CMakeFiles/versionmanager_src.dir/versionmanager_src_autogen/moc_compilation.cpp.o ../libs/kmemoryinfo/CMakeFiles/kmemoryinfo_src.dir/kmemoryinfo.cpp.o ../libs/kmemoryinfo/CMakeFiles/kmemoryinfo_src.dir/kmemoryinfo_src_autogen/moc_compilation.cpp.o ../libs/dngwriter/CMakeFiles/dngwriter_src.dir/dngwriter.cpp.o ../libs/dngwriter/CMakeFiles/dngwriter_src.dir/dngwriter_p.cpp.o ../libs/dngwriter/CMakeFiles/dngwriter_src.dir/dngwriterhost.cpp.o ../libs/dngwriter/CMakeFiles/dngwriter_src.dir/dngsettings.cpp.o ../libs/dngwriter/CMakeFiles/dngwriter_src.dir/dngwriter_src_autogen/moc_compilation.cpp.o ../libs/rawengine/CMakeFiles/rawengine_srcs.dir/drawdecoder.cpp.o ../libs/rawengine/CMakeFiles/rawengine_srcs.dir/drawdecoder_p.cpp.o ../libs/rawengine/CMakeFiles/rawengine_srcs.dir/drawdecodersettings.cpp.o ../libs/rawengine/CMakeFiles/rawengine_srcs.dir/rawinfo.cpp.o ../libs/rawengine/CMakeFiles/rawengine_srcs.dir/rawengine_srcs_autogen/moc_compilation.cpp.o ../libs/facesengine/CMakeFiles/digikamfacesengine_src.dir/opencv3-face/facerec.cpp.o ../libs/facesengine/CMakeFiles/digikamfacesengine_src.dir/opencv3-face/lbph_faces.cpp.o ../libs/facesengine/CMakeFiles/digikamfacesengine_src.dir/opencv3-face/eigen_faces.cpp.o ../libs/facesengine/CMakeFiles/digikamfacesengine_src.dir/opencv3-face/fisher_faces.cpp.o ../libs/facesengine/CMakeFiles/digikamfacesengine_src.dir/opencv3-face/predict_collector.cpp.o ../libs/facesengine/CMakeFiles/digikamfacesengine_src.dir/detection/opencvfacedetector.cpp.o ../libs/facesengine/CMakeFiles/digikamfacesengine_src.dir/shape-predictor/fullobjectdetection.cpp.o ../libs/facesengine/CMakeFiles/digikamfacesengine_src.dir/shape-predictor/qdatastreamoverloads.cpp.o ../libs/facesengine/CMakeFiles/digikamfacesengine_src.dir/facedetector.cpp.o ../libs/facesengine/CMakeFiles/digikamfacesengine_src.dir/identity.cpp.o ../libs/facesengine/CMakeFiles/digikamfacesengine_src.dir/dataproviders.cpp.o ../libs/facesengine/CMakeFiles/digikamfacesengine_src.dir/digikamfacesengine_src_autogen/moc_compilation.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/mainview/dxmlguiwindow.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/mainview/daboutdata.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/mainview/dzoombar.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/mainview/dlogoaction.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/mainview/ditemtooltip.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/mainview/dcursortracker.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/mainview/thumbbardock.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/mainview/thememanager.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/mainview/schememanager.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/mainview/sidebar.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/mainview/dmessagebox.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/mainview/dsplashscreen.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/mainview/fullscreensettings.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/__/__/app/utils/digikam_globals.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/common/abstractitemdragdrophandler.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/common/buttonicondisabler.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/common/dsliderspinbox.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/common/dnuminput.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/common/dexpanderbox.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/common/dactivelabel.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/common/dragdropimplementations.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/common/modelcompleter.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/common/searchtextbar.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/common/statesavingobject.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/common/visibilitycontroller.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/common/dlayoutbox.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/graphicsview/clickdragreleaseitem.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/graphicsview/dimgchilditem.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/graphicsview/dimgpreviewitem.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/graphicsview/regionframeitem.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/graphicsview/graphicsdimgitem.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/graphicsview/graphicsdimgview.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/graphicsview/imagezoomsettings.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/graphicsview/previewlayout.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/graphicsview/paniconwidget.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/graphicsview/itemvisibilitycontroller.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/iccprofiles/iccpreviewwidget.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/iccprofiles/iccprofilewidget.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/iccprofiles/cietonguewidget.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/iccprofiles/iccprofilescombobox.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/itemview/dcategorizedview.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/itemview/dcategorizedsortfilterproxymodel.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/itemview/ditemdelegate.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/itemview/dcategorydrawer.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/itemview/imagedelegateoverlay.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/itemview/itemviewhoverbutton.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/itemview/itemviewimagedelegate.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/itemview/itemviewtooltip.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/itemview/itemviewcategorized.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/itemview/actioncategorizedview.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/metadata/mdkeylistviewitem.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/metadata/metadatalistview.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/metadata/metadatalistviewitem.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/metadata/metadatawidget.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/metadata/metadataselector.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/metadata/metadatapanel.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/metadata/iptcwidget.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/metadata/exifwidget.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/metadata/makernotewidget.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/metadata/xmpwidget.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/metadata/ratingwidget.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/metadata/colorlabelwidget.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/metadata/picklabelwidget.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/metadata/altlangstredit.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/metadata/countryselector.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/metadata/subjectwidget.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/colors/dcolorvalueselector.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/colors/dhuesaturationselect.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/colors/dcolorchoosermode.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/colors/dcolorselector.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/colors/colorgradientwidget.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/colors/dgradientslider.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/fonts/dfontproperties.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/fonts/dfontselect.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/files/filesaveoptionsbox.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/files/filesaveconflictbox.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/files/dfileselector.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/files/dbinarysearch.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/files/dbinaryiface.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/files/drawdecoderwidget.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/combo/comboboxutilities.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/combo/dcombobox.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/combo/squeezedcombobox.cpp.o ../libs/widgets/CMakeFiles/digikamwidgetscore_src.dir/digikamwidgetscore_src_autogen/moc_compilation.cpp.o ../libs/dialogs/CMakeFiles/digikamdialogscore_src.dir/dprogressdlg.cpp.o ../libs/dialogs/CMakeFiles/digikamdialogscore_src.dir/dbusydlg.cpp.o ../libs/dialogs/CMakeFiles/digikamdialogscore_src.dir/filesaveoptionsdlg.cpp.o ../libs/dialogs/CMakeFiles/digikamdialogscore_src.dir/iccprofileinfodlg.cpp.o ../libs/dialogs/CMakeFiles/digikamdialogscore_src.dir/imagedialog.cpp.o ../libs/dialogs/CMakeFiles/digikamdialogscore_src.dir/infodlg.cpp.o ../libs/dialogs/CMakeFiles/digikamdialogscore_src.dir/libsinfodlg.cpp.o ../libs/dialogs/CMakeFiles/digikamdialogscore_src.dir/rawcameradlg.cpp.o ../libs/dialogs/CMakeFiles/digikamdialogscore_src.dir/dconfigdlg.cpp.o ../libs/dialogs/CMakeFiles/digikamdialogscore_src.dir/dconfigdlgmodels.cpp.o ../libs/dialogs/CMakeFiles/digikamdialogscore_src.dir/dconfigdlgview.cpp.o ../libs/dialogs/CMakeFiles/digikamdialogscore_src.dir/dconfigdlgview_p.cpp.o ../libs/dialogs/CMakeFiles/digikamdialogscore_src.dir/dconfigdlgwidgets.cpp.o ../libs/dialogs/CMakeFiles/digikamdialogscore_src.dir/digikamdialogscore_src_autogen/moc_compilation.cpp.o ../libs/imageproperties/CMakeFiles/imageproperties_src.dir/imagepropertiessidebar.cpp.o ../libs/imageproperties/CMakeFiles/imageproperties_src.dir/imagepropertiestab.cpp.o ../libs/imageproperties/CMakeFiles/imageproperties_src.dir/imagepropertiesmetadatatab.cpp.o ../libs/imageproperties/CMakeFiles/imageproperties_src.dir/imagepropertiescolorstab.cpp.o ../libs/imageproperties/CMakeFiles/imageproperties_src.dir/imagepropertiesgpstab.cpp.o ../libs/imageproperties/CMakeFiles/imageproperties_src.dir/imagegpsmodelhelper.cpp.o ../libs/imageproperties/CMakeFiles/imageproperties_src.dir/imageproperties_src_autogen/moc_compilation.cpp.o ../libs/models/CMakeFiles/digikamgenericmodels_src.dir/categorizeditemmodel.cpp.o ../libs/models/CMakeFiles/digikamgenericmodels_src.dir/digikamgenericmodels_src_autogen/moc_compilation.cpp.o ../libs/notificationmanager/CMakeFiles/notificationmanager_src.dir/dnotificationwrapper.cpp.o ../libs/notificationmanager/CMakeFiles/notificationmanager_src.dir/dnotificationpopup.cpp.o ../libs/notificationmanager/CMakeFiles/notificationmanager_src.dir/dnotificationwidget.cpp.o ../libs/notificationmanager/CMakeFiles/notificationmanager_src.dir/dnotificationwidget_p.cpp.o ../libs/notificationmanager/CMakeFiles/notificationmanager_src.dir/notificationmanager_src_autogen/moc_compilation.cpp.o ../utilities/slideshow/CMakeFiles/slideshow_src.dir/slidetoolbar.cpp.o ../utilities/slideshow/CMakeFiles/slideshow_src.dir/slideosd.cpp.o ../utilities/slideshow/CMakeFiles/slideshow_src.dir/slideproperties.cpp.o ../utilities/slideshow/CMakeFiles/slideshow_src.dir/slideimage.cpp.o ../utilities/slideshow/CMakeFiles/slideshow_src.dir/slideerror.cpp.o ../utilities/slideshow/CMakeFiles/slideshow_src.dir/slideend.cpp.o ../utilities/slideshow/CMakeFiles/slideshow_src.dir/slideshow.cpp.o ../utilities/slideshow/CMakeFiles/slideshow_src.dir/slidehelp.cpp.o ../utilities/slideshow/CMakeFiles/slideshow_src.dir/slideshowsettings.cpp.o ../utilities/slideshow/CMakeFiles/slideshow_src.dir/slidevideo.cpp.o ../utilities/slideshow/CMakeFiles/slideshow_src.dir/slideshow_src_autogen/moc_compilation.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/core/undocache.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/core/undoaction.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/core/undomanager.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/core/editorcore.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/core/iccpostloadingmanager.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/dialogs/colorcorrectiondlg.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/dialogs/softproofdialog.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/dialogs/versioningpromptusersavedlg.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/editor/editortool.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/editor/editortooliface.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/editor/editorstackview.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/editor/editortoolsettings.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/editor/editorwindow.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/editor/imageiface.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/printiface/printhelper.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/printiface/printoptionspage.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/printiface/printconfig.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/rawimport/rawimport.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/rawimport/rawpreview.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/rawimport/rawsettingsbox.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/widgets/imageguidewidget.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/widgets/imagepreviewitem.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/widgets/previewtoolbar.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/widgets/previewlist.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/widgets/imageregionwidget.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/widgets/imageregionitem.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/widgets/rubberitem.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/widgets/canvas.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/tools/decorate/inserttextwidget.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/tools/decorate/inserttexttool.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/tools/decorate/bordertool.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/tools/decorate/texturetool.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/tools/filters/colorfxtool.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/tools/filters/charcoaltool.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/tools/filters/embosstool.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/tools/filters/oilpainttool.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/tools/filters/blurfxtool.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/tools/filters/distortionfxtool.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/tools/filters/raindroptool.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/tools/filters/filmgraintool.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/tools/colors/autocorrectiontool.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/tools/colors/bcgtool.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/tools/colors/bwsepiatool.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/tools/colors/profileconversiontool.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/tools/colors/cbtool.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/tools/colors/whitebalancetool.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/tools/colors/hsltool.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/tools/colors/channelmixertool.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/tools/colors/adjustcurvestool.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/tools/colors/adjustlevelstool.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/tools/colors/filmtool.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/tools/enhance/restorationtool.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/tools/enhance/blurtool.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/tools/enhance/sharpentool.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/tools/enhance/noisereductiontool.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/tools/enhance/localcontrasttool.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/tools/enhance/redeyetool.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/tools/enhance/inpaintingtool.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/tools/enhance/antivignettingtool.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/tools/enhance/lensdistortiontool.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/tools/enhance/hotpixels/weights.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/tools/enhance/hotpixels/blackframeparser.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/tools/enhance/hotpixels/blackframelistview.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/tools/enhance/hotpixels/hotpixelfixer.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/tools/enhance/hotpixels/hotpixelstool.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/tools/transform/freerotationtool.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/tools/transform/sheartool.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/tools/transform/resizetool.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/tools/transform/perspectivetool.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/tools/transform/perspectivewidget.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/tools/transform/triangle.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/tools/transform/matrix.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/tools/transform/imageselectionwidget.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/tools/transform/ratiocroptool.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/tools/transform/contentawareresizetool.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/tools/enhance/lensautofixtool.cpp.o ../utilities/imageeditor/CMakeFiles/imageeditor_src.dir/imageeditor_src_autogen/moc_compilation.cpp.o ../utilities/metadataedit/CMakeFiles/metadataedit_src.dir/exif/exifeditwidget.cpp.o ../utilities/metadataedit/CMakeFiles/metadataedit_src.dir/exif/exifcaption.cpp.o ../utilities/metadataedit/CMakeFiles/metadataedit_src.dir/exif/exifdatetime.cpp.o ../utilities/metadataedit/CMakeFiles/metadataedit_src.dir/exif/exifadjust.cpp.o ../utilities/metadataedit/CMakeFiles/metadataedit_src.dir/exif/exiflens.cpp.o ../utilities/metadataedit/CMakeFiles/metadataedit_src.dir/exif/exifdevice.cpp.o ../utilities/metadataedit/CMakeFiles/metadataedit_src.dir/exif/exiflight.cpp.o ../utilities/metadataedit/CMakeFiles/metadataedit_src.dir/iptc/iptceditwidget.cpp.o ../utilities/metadataedit/CMakeFiles/metadataedit_src.dir/iptc/iptccontent.cpp.o ../utilities/metadataedit/CMakeFiles/metadataedit_src.dir/iptc/iptcsubjects.cpp.o ../utilities/metadataedit/CMakeFiles/metadataedit_src.dir/iptc/iptckeywords.cpp.o ../utilities/metadataedit/CMakeFiles/metadataedit_src.dir/iptc/iptccategories.cpp.o ../utilities/metadataedit/CMakeFiles/metadataedit_src.dir/iptc/iptccredits.cpp.o ../utilities/metadataedit/CMakeFiles/metadataedit_src.dir/iptc/iptcproperties.cpp.o ../utilities/metadataedit/CMakeFiles/metadataedit_src.dir/iptc/iptcstatus.cpp.o ../utilities/metadataedit/CMakeFiles/metadataedit_src.dir/iptc/iptcorigin.cpp.o ../utilities/metadataedit/CMakeFiles/metadataedit_src.dir/iptc/iptcenvelope.cpp.o ../utilities/metadataedit/CMakeFiles/metadataedit_src.dir/xmp/xmpeditwidget.cpp.o ../utilities/metadataedit/CMakeFiles/metadataedit_src.dir/xmp/xmpcontent.cpp.o ../utilities/metadataedit/CMakeFiles/metadataedit_src.dir/xmp/xmpkeywords.cpp.o ../utilities/metadataedit/CMakeFiles/metadataedit_src.dir/xmp/xmpcategories.cpp.o ../utilities/metadataedit/CMakeFiles/metadataedit_src.dir/xmp/xmpsubjects.cpp.o ../utilities/metadataedit/CMakeFiles/metadataedit_src.dir/xmp/xmporigin.cpp.o ../utilities/metadataedit/CMakeFiles/metadataedit_src.dir/xmp/xmpcredits.cpp.o ../utilities/metadataedit/CMakeFiles/metadataedit_src.dir/xmp/xmpstatus.cpp.o ../utilities/metadataedit/CMakeFiles/metadataedit_src.dir/xmp/xmpproperties.cpp.o ../utilities/metadataedit/CMakeFiles/metadataedit_src.dir/dialog/metadatacheckbox.cpp.o ../utilities/metadataedit/CMakeFiles/metadataedit_src.dir/dialog/timezonecombobox.cpp.o ../utilities/metadataedit/CMakeFiles/metadataedit_src.dir/dialog/altlangstringedit.cpp.o ../utilities/metadataedit/CMakeFiles/metadataedit_src.dir/dialog/multistringsedit.cpp.o ../utilities/metadataedit/CMakeFiles/metadataedit_src.dir/dialog/multivaluesedit.cpp.o ../utilities/metadataedit/CMakeFiles/metadataedit_src.dir/dialog/objectattributesedit.cpp.o ../utilities/metadataedit/CMakeFiles/metadataedit_src.dir/dialog/metadataedit.cpp.o ../utilities/metadataedit/CMakeFiles/metadataedit_src.dir/metadataedit_src_autogen/moc_compilation.cpp.o ../utilities/assistants/expoblending/CMakeFiles/expoblending_src.dir/manager/expoblendingmanager.cpp.o ../utilities/assistants/expoblending/CMakeFiles/expoblending_src.dir/manager/expoblendingthread.cpp.o ../utilities/assistants/expoblending/CMakeFiles/expoblending_src.dir/manager/enfusebinary.cpp.o ../utilities/assistants/expoblending/CMakeFiles/expoblending_src.dir/wizard/expoblendingwizard.cpp.o ../utilities/assistants/expoblending/CMakeFiles/expoblending_src.dir/wizard/expoblendingintropage.cpp.o ../utilities/assistants/expoblending/CMakeFiles/expoblending_src.dir/wizard/expoblendingitemspage.cpp.o ../utilities/assistants/expoblending/CMakeFiles/expoblending_src.dir/wizard/expoblendingpreprocesspage.cpp.o ../utilities/assistants/expoblending/CMakeFiles/expoblending_src.dir/wizard/expoblendinglastpage.cpp.o ../utilities/assistants/expoblending/CMakeFiles/expoblending_src.dir/blendingdlg/enfusesettings.cpp.o ../utilities/assistants/expoblending/CMakeFiles/expoblending_src.dir/blendingdlg/bracketstack.cpp.o ../utilities/assistants/expoblending/CMakeFiles/expoblending_src.dir/blendingdlg/enfusestack.cpp.o ../utilities/assistants/expoblending/CMakeFiles/expoblending_src.dir/blendingdlg/expoblendingdlg.cpp.o ../utilities/assistants/expoblending/CMakeFiles/expoblending_src.dir/expoblending_src_autogen/moc_compilation.cpp.o ../utilities/assistants/common/CMakeFiles/assistants_src.dir/dwizardpage.cpp.o ../utilities/assistants/common/CMakeFiles/assistants_src.dir/dwizarddlg.cpp.o ../utilities/assistants/common/CMakeFiles/assistants_src.dir/dsavesettingswidget.cpp.o ../utilities/assistants/common/CMakeFiles/assistants_src.dir/dpreviewmanager.cpp.o ../utilities/assistants/common/CMakeFiles/assistants_src.dir/dpreviewimage.cpp.o ../utilities/assistants/common/CMakeFiles/assistants_src.dir/dimageslist.cpp.o ../utilities/assistants/common/CMakeFiles/assistants_src.dir/dinfointerface.cpp.o ../utilities/assistants/common/CMakeFiles/assistants_src.dir/assistants_src_autogen/moc_compilation.cpp.o ../utilities/presentation/CMakeFiles/presentation_src.dir/dialogs/presentation_captionpage.cpp.o ../utilities/presentation/CMakeFiles/presentation_src.dir/dialogs/presentation_advpage.cpp.o ../utilities/presentation/CMakeFiles/presentation_src.dir/widgets/presentationctrlwidget.cpp.o ../utilities/presentation/CMakeFiles/presentation_src.dir/widgets/presentationwidget.cpp.o ../utilities/presentation/CMakeFiles/presentation_src.dir/common/presentationcontainer.cpp.o ../utilities/presentation/CMakeFiles/presentation_src.dir/common/presentationloader.cpp.o ../utilities/presentation/CMakeFiles/presentation_src.dir/dialogs/presentationdlg.cpp.o ../utilities/presentation/CMakeFiles/presentation_src.dir/dialogs/presentation_mainpage.cpp.o ../utilities/presentation/CMakeFiles/presentation_src.dir/presentationmngr.cpp.o ../utilities/presentation/CMakeFiles/presentation_src.dir/opengl/presentationgl.cpp.o ../utilities/presentation/CMakeFiles/presentation_src.dir/opengl/presentationkb.cpp.o ../utilities/presentation/CMakeFiles/presentation_src.dir/opengl/kbeffect.cpp.o ../utilities/presentation/CMakeFiles/presentation_src.dir/opengl/kbimageloader.cpp.o ../utilities/presentation/CMakeFiles/presentation_src.dir/audio/presentationaudiolist.cpp.o ../utilities/presentation/CMakeFiles/presentation_src.dir/audio/presentation_audiopage.cpp.o ../utilities/presentation/CMakeFiles/presentation_src.dir/audio/presentationaudiowidget.cpp.o ../utilities/presentation/CMakeFiles/presentation_src.dir/presentation_src_autogen/moc_compilation.cpp.o ../libs/transitionmngr/CMakeFiles/digikamlibtransitionmngr_src.dir/effectpreview.cpp.o ../libs/transitionmngr/CMakeFiles/digikamlibtransitionmngr_src.dir/effectmngr.cpp.o ../libs/transitionmngr/CMakeFiles/digikamlibtransitionmngr_src.dir/effectmngr_p.cpp.o ../libs/transitionmngr/CMakeFiles/digikamlibtransitionmngr_src.dir/effectmngr_p_pan.cpp.o ../libs/transitionmngr/CMakeFiles/digikamlibtransitionmngr_src.dir/effectmngr_p_zoom.cpp.o ../libs/transitionmngr/CMakeFiles/digikamlibtransitionmngr_src.dir/frameutils.cpp.o ../libs/transitionmngr/CMakeFiles/digikamlibtransitionmngr_src.dir/transitionpreview.cpp.o ../libs/transitionmngr/CMakeFiles/digikamlibtransitionmngr_src.dir/transitionmngr.cpp.o ../libs/transitionmngr/CMakeFiles/digikamlibtransitionmngr_src.dir/transitionmngr_p.cpp.o ../libs/transitionmngr/CMakeFiles/digikamlibtransitionmngr_src.dir/transitionmngr_p_abstract.cpp.o ../libs/transitionmngr/CMakeFiles/digikamlibtransitionmngr_src.dir/transitionmngr_p_blur.cpp.o ../libs/transitionmngr/CMakeFiles/digikamlibtransitionmngr_src.dir/transitionmngr_p_lines.cpp.o ../libs/transitionmngr/CMakeFiles/digikamlibtransitionmngr_src.dir/transitionmngr_p_push.cpp.o ../libs/transitionmngr/CMakeFiles/digikamlibtransitionmngr_src.dir/transitionmngr_p_slide.cpp.o ../libs/transitionmngr/CMakeFiles/digikamlibtransitionmngr_src.dir/transitionmngr_p_squares.cpp.o ../libs/transitionmngr/CMakeFiles/digikamlibtransitionmngr_src.dir/transitionmngr_p_swap.cpp.o ../libs/transitionmngr/CMakeFiles/digikamlibtransitionmngr_src.dir/digikamlibtransitionmngr_src_autogen/moc_compilation.cpp.o ../utilities/kdesupport/akonadi/CMakeFiles/akonadiiface_src.dir/akonadiiface.cpp.o ../utilities/kdesupport/akonadi/CMakeFiles/akonadiiface_src.dir/akonadiiface_src_autogen/moc_compilation.cpp.o ../utilities/assistants/calendar/CMakeFiles/calendar_src.dir/print/calsettings.cpp.o ../utilities/assistants/calendar/CMakeFiles/calendar_src.dir/print/calpainter.cpp.o ../utilities/assistants/calendar/CMakeFiles/calendar_src.dir/print/calprinter.cpp.o ../utilities/assistants/calendar/CMakeFiles/calendar_src.dir/print/calsystem.cpp.o ../utilities/assistants/calendar/CMakeFiles/calendar_src.dir/wizard/calmonthwidget.cpp.o ../utilities/assistants/calendar/CMakeFiles/calendar_src.dir/wizard/caltemplate.cpp.o ../utilities/assistants/calendar/CMakeFiles/calendar_src.dir/wizard/calwidget.cpp.o ../utilities/assistants/calendar/CMakeFiles/calendar_src.dir/wizard/calwizard.cpp.o ../utilities/assistants/calendar/CMakeFiles/calendar_src.dir/calendar_src_autogen/moc_compilation.cpp.o ../utilities/geolocation/geoiface/CMakeFiles/geoiface_src.dir/backends/mapbackend.cpp.o ../utilities/geolocation/geoiface/CMakeFiles/geoiface_src.dir/backends/htmlwidget.cpp.o ../utilities/geolocation/geoiface/CMakeFiles/geoiface_src.dir/backends/backendmarble.cpp.o ../utilities/geolocation/geoiface/CMakeFiles/geoiface_src.dir/backends/backendmarblelayer.cpp.o ../utilities/geolocation/geoiface/CMakeFiles/geoiface_src.dir/backends/backendgooglemaps.cpp.o ../utilities/geolocation/geoiface/CMakeFiles/geoiface_src.dir/abstractmarkertiler.cpp.o ../utilities/geolocation/geoiface/CMakeFiles/geoiface_src.dir/dragdrophandler.cpp.o ../utilities/geolocation/geoiface/CMakeFiles/geoiface_src.dir/geocoordinates.cpp.o ../utilities/geolocation/geoiface/CMakeFiles/geoiface_src.dir/groupstatecomputer.cpp.o ../utilities/geolocation/geoiface/CMakeFiles/geoiface_src.dir/itemmarkertiler.cpp.o ../utilities/geolocation/geoiface/CMakeFiles/geoiface_src.dir/geoiface_common.cpp.o ../utilities/geolocation/geoiface/CMakeFiles/geoiface_src.dir/lookupaltitude.cpp.o ../utilities/geolocation/geoiface/CMakeFiles/geoiface_src.dir/lookupaltitudegeonames.cpp.o ../utilities/geolocation/geoiface/CMakeFiles/geoiface_src.dir/lookupfactory.cpp.o ../utilities/geolocation/geoiface/CMakeFiles/geoiface_src.dir/mapwidget.cpp.o ../utilities/geolocation/geoiface/CMakeFiles/geoiface_src.dir/modelhelper.cpp.o ../utilities/geolocation/geoiface/CMakeFiles/geoiface_src.dir/placeholderwidget.cpp.o ../utilities/geolocation/geoiface/CMakeFiles/geoiface_src.dir/tilegrouper.cpp.o ../utilities/geolocation/geoiface/CMakeFiles/geoiface_src.dir/tileindex.cpp.o ../utilities/geolocation/geoiface/CMakeFiles/geoiface_src.dir/trackreader.cpp.o ../utilities/geolocation/geoiface/CMakeFiles/geoiface_src.dir/tracks.cpp.o ../utilities/geolocation/geoiface/CMakeFiles/geoiface_src.dir/ECMQmLoader-marble_qt.cpp.o ../utilities/geolocation/geoiface/CMakeFiles/geoiface_src.dir/geoiface_src_autogen/moc_compilation.cpp.o ../utilities/geolocation/geomapwrapper/CMakeFiles/geomapwrapper_src.dir/gpsimageinfo.cpp.o ../utilities/geolocation/geomapwrapper/CMakeFiles/geomapwrapper_src.dir/gpsimageinfosorter.cpp.o ../utilities/geolocation/geomapwrapper/CMakeFiles/geomapwrapper_src.dir/geomapwrapper_src_autogen/moc_compilation.cpp.o ../utilities/geolocation/editor/CMakeFiles/geolocationedit_src.dir/backends/backend-rg.cpp.o ../utilities/geolocation/editor/CMakeFiles/geolocationedit_src.dir/backends/backend-geonames-rg.cpp.o ../utilities/geolocation/editor/CMakeFiles/geolocationedit_src.dir/backends/backend-geonamesUS-rg.cpp.o ../utilities/geolocation/editor/CMakeFiles/geolocationedit_src.dir/backends/backend-osm-rg.cpp.o ../utilities/geolocation/editor/CMakeFiles/geolocationedit_src.dir/correlator/track_correlator.cpp.o ../utilities/geolocation/editor/CMakeFiles/geolocationedit_src.dir/correlator/track_correlator_thread.cpp.o ../utilities/geolocation/editor/CMakeFiles/geolocationedit_src.dir/correlator/track_listmodel.cpp.o ../utilities/geolocation/editor/CMakeFiles/geolocationedit_src.dir/correlator/gpscorrelatorwidget.cpp.o ../utilities/geolocation/editor/CMakeFiles/geolocationedit_src.dir/reversegeocoding/rginfo.cpp.o ../utilities/geolocation/editor/CMakeFiles/geolocationedit_src.dir/reversegeocoding/rgtagmodel.cpp.o ../utilities/geolocation/editor/CMakeFiles/geolocationedit_src.dir/reversegeocoding/rgwidget.cpp.o ../utilities/geolocation/editor/CMakeFiles/geolocationedit_src.dir/reversegeocoding/simpletreemodel.cpp.o ../utilities/geolocation/editor/CMakeFiles/geolocationedit_src.dir/searches/searchbackend.cpp.o ../utilities/geolocation/editor/CMakeFiles/geolocationedit_src.dir/searches/searchresultmodel.cpp.o ../utilities/geolocation/editor/CMakeFiles/geolocationedit_src.dir/searches/searchresultmodelhelper.cpp.o ../utilities/geolocation/editor/CMakeFiles/geolocationedit_src.dir/searches/searchwidget.cpp.o ../utilities/geolocation/editor/CMakeFiles/geolocationedit_src.dir/dragdrop/mapdragdrophandler.cpp.o ../utilities/geolocation/editor/CMakeFiles/geolocationedit_src.dir/dragdrop/gpsimagelistdragdrophandler.cpp.o ../utilities/geolocation/editor/CMakeFiles/geolocationedit_src.dir/items/gpsimagemodel.cpp.o ../utilities/geolocation/editor/CMakeFiles/geolocationedit_src.dir/items/gpsimagesortproxymodel.cpp.o ../utilities/geolocation/editor/CMakeFiles/geolocationedit_src.dir/items/gpsimageitem.cpp.o ../utilities/geolocation/editor/CMakeFiles/geolocationedit_src.dir/items/gpsimageitemdelegate.cpp.o ../utilities/geolocation/editor/CMakeFiles/geolocationedit_src.dir/items/gpsimagelist.cpp.o ../utilities/geolocation/editor/CMakeFiles/geolocationedit_src.dir/items/gpsimagelistcontextmenu.cpp.o ../utilities/geolocation/editor/CMakeFiles/geolocationedit_src.dir/dialog/gpscommon.cpp.o ../utilities/geolocation/editor/CMakeFiles/geolocationedit_src.dir/dialog/gpsimagedetails.cpp.o ../utilities/geolocation/editor/CMakeFiles/geolocationedit_src.dir/dialog/gpsundocommand.cpp.o ../utilities/geolocation/editor/CMakeFiles/geolocationedit_src.dir/dialog/geolocationedit.cpp.o ../utilities/geolocation/editor/CMakeFiles/geolocationedit_src.dir/dialog/gpsgeoifacemodelhelper.cpp.o ../utilities/geolocation/editor/CMakeFiles/geolocationedit_src.dir/bookmark/gpsbookmarkowner.cpp.o ../utilities/geolocation/editor/CMakeFiles/geolocationedit_src.dir/bookmark/gpsbookmarkmodelhelper.cpp.o ../utilities/geolocation/editor/CMakeFiles/geolocationedit_src.dir/bookmark/bookmarknode.cpp.o ../utilities/geolocation/editor/CMakeFiles/geolocationedit_src.dir/bookmark/bookmarksmenu.cpp.o ../utilities/geolocation/editor/CMakeFiles/geolocationedit_src.dir/bookmark/bookmarksmngr.cpp.o ../utilities/geolocation/editor/CMakeFiles/geolocationedit_src.dir/bookmark/bookmarksdlg.cpp.o ../utilities/geolocation/editor/CMakeFiles/geolocationedit_src.dir/geolocationedit_src_autogen/moc_compilation.cpp.o ../utilities/assistants/panorama/CMakeFiles/panorama_src.dir/ptotype/ptotype.cpp.o ../utilities/assistants/panorama/CMakeFiles/panorama_src.dir/panoScanner.c.o ../utilities/assistants/panorama/CMakeFiles/panorama_src.dir/panoParser.c.o ../utilities/assistants/panorama/CMakeFiles/panorama_src.dir/ptoparser/tparser.c.o ../utilities/assistants/panorama/CMakeFiles/panorama_src.dir/ptoparser/tparserprivate.c.o ../utilities/assistants/panorama/CMakeFiles/panorama_src.dir/ptoparser/tparsergetters.c.o ../utilities/assistants/panorama/CMakeFiles/panorama_src.dir/ptoparser/ptofile.cpp.o ../utilities/assistants/panorama/CMakeFiles/panorama_src.dir/tasks/panotask.cpp.o ../utilities/assistants/panorama/CMakeFiles/panorama_src.dir/tasks/commandtask.cpp.o ../utilities/assistants/panorama/CMakeFiles/panorama_src.dir/tasks/createfinalptotask.cpp.o ../utilities/assistants/panorama/CMakeFiles/panorama_src.dir/tasks/cpfindtask.cpp.o ../utilities/assistants/panorama/CMakeFiles/panorama_src.dir/tasks/cpcleantask.cpp.o ../utilities/assistants/panorama/CMakeFiles/panorama_src.dir/tasks/optimisationtask.cpp.o ../utilities/assistants/panorama/CMakeFiles/panorama_src.dir/tasks/autocroptask.cpp.o ../utilities/assistants/panorama/CMakeFiles/panorama_src.dir/tasks/createmktask.cpp.o ../utilities/assistants/panorama/CMakeFiles/panorama_src.dir/tasks/compilemksteptask.cpp.o ../utilities/assistants/panorama/CMakeFiles/panorama_src.dir/tasks/compilemktask.cpp.o ../utilities/assistants/panorama/CMakeFiles/panorama_src.dir/tasks/huginexecutortask.cpp.o ../utilities/assistants/panorama/CMakeFiles/panorama_src.dir/tasks/copyfilestask.cpp.o ../utilities/assistants/panorama/CMakeFiles/panorama_src.dir/tasks/createpreviewtask.cpp.o ../utilities/assistants/panorama/CMakeFiles/panorama_src.dir/tasks/createptotask.cpp.o ../utilities/assistants/panorama/CMakeFiles/panorama_src.dir/tasks/preprocesstask.cpp.o ../utilities/assistants/panorama/CMakeFiles/panorama_src.dir/manager/cpfindbinary.cpp.o ../utilities/assistants/panorama/CMakeFiles/panorama_src.dir/manager/panoactionthread.cpp.o ../utilities/assistants/panorama/CMakeFiles/panorama_src.dir/manager/panomanager.cpp.o ../utilities/assistants/panorama/CMakeFiles/panorama_src.dir/wizard/panointropage.cpp.o ../utilities/assistants/panorama/CMakeFiles/panorama_src.dir/wizard/panoitemspage.cpp.o ../utilities/assistants/panorama/CMakeFiles/panorama_src.dir/wizard/panolastpage.cpp.o ../utilities/assistants/panorama/CMakeFiles/panorama_src.dir/wizard/panooptimizepage.cpp.o ../utilities/assistants/panorama/CMakeFiles/panorama_src.dir/wizard/panopreprocesspage.cpp.o ../utilities/assistants/panorama/CMakeFiles/panorama_src.dir/wizard/panopreviewpage.cpp.o ../utilities/assistants/panorama/CMakeFiles/panorama_src.dir/wizard/panowizard.cpp.o ../utilities/assistants/panorama/CMakeFiles/panorama_src.dir/panorama_src_autogen/moc_compilation.cpp.o ../utilities/assistants/htmlgallery/CMakeFiles/htmlgallery_src.dir/parameters/abstractthemeparameter.cpp.o ../utilities/assistants/htmlgallery/CMakeFiles/htmlgallery_src.dir/parameters/intthemeparameter.cpp.o ../utilities/assistants/htmlgallery/CMakeFiles/htmlgallery_src.dir/parameters/listthemeparameter.cpp.o ../utilities/assistants/htmlgallery/CMakeFiles/htmlgallery_src.dir/parameters/stringthemeparameter.cpp.o ../utilities/assistants/htmlgallery/CMakeFiles/htmlgallery_src.dir/parameters/colorthemeparameter.cpp.o ../utilities/assistants/htmlgallery/CMakeFiles/htmlgallery_src.dir/wizard/invisiblebuttongroup.cpp.o ../utilities/assistants/htmlgallery/CMakeFiles/htmlgallery_src.dir/wizard/htmlintropage.cpp.o ../utilities/assistants/htmlgallery/CMakeFiles/htmlgallery_src.dir/wizard/htmlselectionpage.cpp.o ../utilities/assistants/htmlgallery/CMakeFiles/htmlgallery_src.dir/wizard/htmlthemepage.cpp.o ../utilities/assistants/htmlgallery/CMakeFiles/htmlgallery_src.dir/wizard/htmloutputpage.cpp.o ../utilities/assistants/htmlgallery/CMakeFiles/htmlgallery_src.dir/wizard/htmlfinalpage.cpp.o ../utilities/assistants/htmlgallery/CMakeFiles/htmlgallery_src.dir/wizard/htmlimagesettingspage.cpp.o ../utilities/assistants/htmlgallery/CMakeFiles/htmlgallery_src.dir/wizard/htmlparameterspage.cpp.o ../utilities/assistants/htmlgallery/CMakeFiles/htmlgallery_src.dir/wizard/htmlwizard.cpp.o ../utilities/assistants/htmlgallery/CMakeFiles/htmlgallery_src.dir/generator/galleryxmlutils.cpp.o ../utilities/assistants/htmlgallery/CMakeFiles/htmlgallery_src.dir/generator/gallerynamehelper.cpp.o ../utilities/assistants/htmlgallery/CMakeFiles/htmlgallery_src.dir/generator/galleryelementfunctor.cpp.o ../utilities/assistants/htmlgallery/CMakeFiles/htmlgallery_src.dir/generator/galleryconfig.cpp.o ../utilities/assistants/htmlgallery/CMakeFiles/htmlgallery_src.dir/generator/galleryelement.cpp.o ../utilities/assistants/htmlgallery/CMakeFiles/htmlgallery_src.dir/generator/gallerytheme.cpp.o ../utilities/assistants/htmlgallery/CMakeFiles/htmlgallery_src.dir/generator/galleryinfo.cpp.o ../utilities/assistants/htmlgallery/CMakeFiles/htmlgallery_src.dir/generator/gallerygenerator.cpp.o ../utilities/assistants/htmlgallery/CMakeFiles/htmlgallery_src.dir/htmlgallery_src_autogen/moc_compilation.cpp.o ../utilities/assistants/videoslideshow/CMakeFiles/videoslideshow_src.dir/wizard/vidslidewizard.cpp.o ../utilities/assistants/videoslideshow/CMakeFiles/videoslideshow_src.dir/wizard/vidslideintropage.cpp.o ../utilities/assistants/videoslideshow/CMakeFiles/videoslideshow_src.dir/wizard/vidslidealbumspage.cpp.o ../utilities/assistants/videoslideshow/CMakeFiles/videoslideshow_src.dir/wizard/vidslideimagespage.cpp.o ../utilities/assistants/videoslideshow/CMakeFiles/videoslideshow_src.dir/wizard/vidslidevideopage.cpp.o ../utilities/assistants/videoslideshow/CMakeFiles/videoslideshow_src.dir/wizard/vidslideoutputpage.cpp.o ../utilities/assistants/videoslideshow/CMakeFiles/videoslideshow_src.dir/wizard/vidslidefinalpage.cpp.o ../utilities/assistants/videoslideshow/CMakeFiles/videoslideshow_src.dir/manager/vidslidesettings.cpp.o ../utilities/assistants/videoslideshow/CMakeFiles/videoslideshow_src.dir/manager/vidslidethread.cpp.o ../utilities/assistants/videoslideshow/CMakeFiles/videoslideshow_src.dir/manager/vidslidetask.cpp.o ../utilities/assistants/videoslideshow/CMakeFiles/videoslideshow_src.dir/player/vidplayerdlg.cpp.o ../utilities/assistants/videoslideshow/CMakeFiles/videoslideshow_src.dir/player/mediaplayerview.cpp.o ../utilities/assistants/videoslideshow/CMakeFiles/videoslideshow_src.dir/videoslideshow_src_autogen/moc_compilation.cpp.o -Wl,-rpath,/opt/local/lib/x86_64-linux-gnu:/opt/local/libexec/qt5/lib /opt/local/libexec/qt5/lib/libQt5Sql.so.5.8.0 /opt/local/libexec/qt5/lib/libQt5WebKitWidgets.so.5.8.0 -lpthread -llcms2 -ltiff -lpng -lz -lexiv2 ../libs/dngwriter/liblibdng.a ../libs/rawengine/libraw/liblibraw.a /opt/local/lib/x86_64-linux-gnu/libKF5Kipi.so.5.2.0 /opt/local/lib/x86_64-linux-gnu/libKF5NotifyConfig.so.5.35.0 -lmarblewidget-qt5 -lSM -lICE -lX11 -lXext -ljasper -ljpeg -llqr-1 -lglib-2.0 -lintl -llensfun /opt/local/lib/libopencv_objdetect.so.3.2.0 ../utilities/kdesupport/kfilemetadata/libbaloowrap.a -lGLU -lGL /opt/local/lib/x86_64-linux-gnu/libKF5CalendarCore.so.5.5.2 /opt/local/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5.35.0 -lexslt -lxslt -lxml2 -lQtAV -lQtAVWidgets /opt/local/libexec/qt5/lib/libQt5WebKit.so.5.8.0 ../libs/dngwriter/liblibdng.a -lpthread ../libs/dngwriter/liblibxmp.a ../libs/dngwriter/liblibmd5.a -lexpat -lm -llcms2 -ljasper -ljpeg /opt/local/lib/libopencv_ml.so.3.2.0 /opt/local/lib/libopencv_highgui.so.3.2.0 /opt/local/libexec/qt5/lib/libQt5OpenGL.so.5.8.0 /opt/local/lib/libopencv_videoio.so.3.2.0 /opt/local/lib/libopencv_imgcodecs.so.3.2.0 /opt/local/lib/libopencv_imgproc.so.3.2.0 /opt/local/lib/libopencv_core.so.3.2.0 /opt/local/lib/x86_64-linux-gnu/libKF5FileMetaData.so.5.35.0 /opt/local/lib/x86_64-linux-gnu/libKF5KDELibs4Support.so.5.35.0 /opt/local/lib/x86_64-linux-gnu/libKF5Notifications.so.5.35.0 /opt/local/lib/x86_64-linux-gnu/libKF5Crash.so.5.35.0 /opt/local/lib/x86_64-linux-gnu/libKF5KIOFileWidgets.so.5.35.0 /opt/local/lib/x86_64-linux-gnu/libKF5Solid.so.5.35.0 /opt/local/lib/x86_64-linux-gnu/libKF5Bookmarks.so.5.35.0 /opt/local/lib/x86_64-linux-gnu/libKF5UnitConversion.so.5.35.0 /opt/local/lib/x86_64-linux-gnu/libKF5Parts.so.5.35.0 /opt/local/lib/x86_64-linux-gnu/libKF5XmlGui.so.5.35.0 /opt/local/libexec/qt5/lib/libQt5PrintSupport.so.5.8.0 /opt/local/lib/x86_64-linux-gnu/libKF5KIOWidgets.so.5.35.0 /opt/local/lib/x86_64-linux-gnu/libKF5KIOCore.so.5.35.0 /opt/local/libexec/qt5/lib/libQt5Concurrent.so.5.8.0 /opt/local/libexec/qt5/lib/libQt5Network.so.5.8.0 /opt/local/lib/x86_64-linux-gnu/libKF5JobWidgets.so.5.35.0 /opt/local/lib/x86_64-linux-gnu/libKF5TextWidgets.so.5.35.0 /opt/local/lib/x86_64-linux-gnu/libKF5WindowSystem.so.5.35.0 /opt/local/lib/x86_64-linux-gnu/libKF5Service.so.5.35.0 /opt/local/lib/x86_64-linux-gnu/libKF5IconThemes.so.5.35.0 /opt/local/lib/x86_64-linux-gnu/libKF5ItemViews.so.5.35.0 /opt/local/lib/x86_64-linux-gnu/libKF5ConfigWidgets.so.5.35.0 /opt/local/lib/x86_64-linux-gnu/libKF5I18n.so.5.35.0 /opt/local/lib/x86_64-linux-gnu/libKF5Codecs.so.5.35.0 /opt/local/lib/x86_64-linux-gnu/libKF5Auth.so.5.35.0 /opt/local/lib/x86_64-linux-gnu/libKF5CoreAddons.so.5.35.0 /opt/local/libexec/qt5/lib/libQt5DBus.so.5.8.0 /opt/local/lib/x86_64-linux-gnu/libKF5GuiAddons.so.5.35.0 /opt/local/libexec/qt5/lib/libQt5X11Extras.so.5.8.0 /opt/local/lib/x86_64-linux-gnu/libKF5Completion.so.5.35.0 /opt/local/lib/x86_64-linux-gnu/libKF5ConfigGui.so.5.35.0 /opt/local/libexec/qt5/lib/libQt5Xml.so.5.8.0 /opt/local/lib/x86_64-linux-gnu/libKF5ConfigCore.so.5.35.0 /opt/local/lib/x86_64-linux-gnu/libKF5WidgetsAddons.so.5.35.0 /opt/local/lib/x86_64-linux-gnu/libKF5SonnetUi.so.5.35.0 /opt/local/libexec/qt5/lib/libQt5Widgets.so.5.8.0 /opt/local/libexec/qt5/lib/libQt5Gui.so.5.8.0 -lical -licalss /opt/local/libexec/qt5/lib/libQt5Core.so.5.8.0 -Wl,-rpath-link,/opt/local/lib/x86_64-linux-gnu ../libs/dimg/CMakeFiles/dimg_src.dir/loaders/pngloader.cpp.o: In function `Digikam::PNGLoader::load(QString const&, Digikam::DImgLoaderObserver*)': /path/to/digikam/work/digikam-5.6.0/core/libs/dimg/loaders/pngloader.cpp:219: undefined reference to `png_set_longjmp_fn' CMakeCache.txt contains this: PNG_LIBRARY_DEBUG:FILEPATH=PNG_LIBRARY_DEBUG-NOTFOUND PNG_LIBRARY_RELEASE:FILEPATH=/opt/local/lib/libpng.so PNG_PNG_INCLUDE_DIR:PATH=/opt/local/include //Details about finding PNG FIND_PACKAGE_MESSAGE_DETAILS_PNG:INTERNAL=[/opt/local/lib/libpng.so][/opt/local/include][v1.6.29()] //ADVANCED property for variable: PNG_LIBRARY_DEBUG PNG_LIBRARY_DEBUG-ADVANCED:INTERNAL=1 //ADVANCED property for variable: PNG_LIBRARY_RELEASE PNG_LIBRARY_RELEASE-ADVANCED:INTERNAL=1 //ADVANCED property for variable: PNG_PNG_INCLUDE_DIR PNG_PNG_INCLUDE_DIR-ADVANCED:INTERNAL=1 the digikamcore target_link_libraries command uses ${PNG_LIBRARIES}: PNG_LIBRARIES=/opt/local/lib/libpng.so;/opt/local/lib/libz.so From brad.king at kitware.com Wed Jul 12 07:47:30 2017 From: brad.king at kitware.com (Brad King) Date: Wed, 12 Jul 2017 07:47:30 -0400 Subject: [cmake-developers] There's several issues with NDK support in CMake 3.9.0 In-Reply-To: References: Message-ID: <61308d3c-6858-35ad-f1f7-98db4b3fb7f8@kitware.com> On 07/11/2017 06:55 PM, Robert Dailey wrote: > https://github.com/android-ndk/ndk/issues/452 I'll join that discussion, thanks. -Brad From eike at sf-mail.de Wed Jul 12 08:22:40 2017 From: eike at sf-mail.de (Rolf Eike Beer) Date: Wed, 12 Jul 2017 14:22:40 +0200 Subject: [cmake-developers] FindPNG.cmake doesn't return a LIBRARY_DIR variable In-Reply-To: <2555015.gigOroPMWN@bola> References: <2555015.gigOroPMWN@bola> Message-ID: Am 2017-07-12 13:35, schrieb Ren? J.V. Bertin: > Hi, > > I routinely use cmake to build projects for installation into a prefix > (/opt/local) and that use libraries from that location which also > exist in the system locations (typically in older versions, in that > case). > > I thus have .pc files under /opt/local which generate linker > instructions of the type "-L/opt/local/lib -lfoo". > > You'd expect this should work, but (too) often I still get linker > errors about symbols not being found which upon verification are in > fact provided by the intended library. In that case the > -L/opt/local/lib is typically given only once on the linker command > line ("way" before the corresponding -l argument), or not at all. See > the example below, where I don't see the -L option at all (linker > output and data from CMakeCache.txt after the HUGE linker command). > > Initially I thought this was a case where one shouldn't filter out > identical -L options because the linker could limit their scope to > just the -l option immediately following the -L, but in this case it > appears that FindPNG.cmake simply doesn't consider the possibility > that libpng might be found in a location that isn't in the standard > library search path. IOW, FindPNG.cmake doesn't return a > PNG_LIBRARY_DIR variable, and provides the full path only in an > obsolete variable (PNG_LIBRARY). And for some reason, the command > `target_link_libraries(digikamcore ... ${PNG_LIBRARIES} ...)` is > translated into `-lpng -lz` . > Is that a bug or feature? First, FindPNG.cmake doesn't care about pkg-config files, if that is bug or feature depends on your personal things. CMake will detect the library using the full path (as it has done), and construct proper -L and -l from that. It doesn't happen here, which makes me suspect that you don't even link to ${PNG_LIBRARIES} or PNG::PNG (the latter being the better version). It seems to me like the -lpng you see comes from QtWebkitWidgets, which would also need to be linked against your library anyway, as things could break in funny ways otherwise (no idea how stable the libPNG API is). Eike -- From ben.boeckel at kitware.com Wed Jul 12 09:14:09 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 12 Jul 2017 09:14:09 -0400 Subject: [cmake-developers] FindPNG.cmake doesn't return a LIBRARY_DIR variable In-Reply-To: References: <2555015.gigOroPMWN@bola> Message-ID: <20170712131409.GA17906@megas.kitware.com> On Wed, Jul 12, 2017 at 14:22:40 +0200, Rolf Eike Beer wrote: > First, FindPNG.cmake doesn't care about pkg-config files, if that is bug > or feature depends on your personal things. CMake will detect the > library using the full path (as it has done), and construct proper -L > and -l from that. CMake prefers using full paths to libraries it finds, so I don't think it would turn a full path into a `-L` and `-l` flag pair. --Ben From rjvbertin at gmail.com Wed Jul 12 12:21:04 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Wed, 12 Jul 2017 18:21:04 +0200 Subject: [cmake-developers] FindPNG.cmake doesn't return a LIBRARY_DIR variable References: <2555015.gigOroPMWN@bola> Message-ID: <31933720.X2ys5czo9W@patux.local> Rolf Eike Beer wrote: > First, FindPNG.cmake doesn't care about pkg-config files, if that is bug Yes, I noticed that after I wrote the remark about the pkg-config files, and didn't think to remove it (= I diagnosed the issue while writing the message). > or feature depends on your personal things. CMake will detect the > library using the full path (as it has done), and construct proper -L > and -l from that. It doesn't happen here, which makes me suspect that > you don't even link to ${PNG_LIBRARIES} or PNG::PNG (the latter being >From the CMake file (digikam-5.6.0/core/app/CMakeLists.txt): target_link_libraries(digikamcore PUBLIC Qt5::Core Qt5::Gui Qt5::Xml Qt5::Widgets Qt5::Sql Qt5::WebKitWidgets Qt5::PrintSupport Qt5::Concurrent KF5::Solid KF5::WindowSystem KF5::ConfigGui KF5::CoreAddons KF5::Service KF5::XmlGui KF5::I18n # Required by CImg which use pthread internally. ${CMAKE_THREAD_LIBS_INIT} ${LCMS2_LIBRARIES} # filters ${TIFF_LIBRARIES} ${PNG_LIBRARIES} ${EXIV2_LIBRARIES} libdng libraw ) > the better version). It seems to me like the -lpng you see comes from > QtWebkitWidgets, which would also need to be linked against your library It does and is, but I don't find a reference to libpng in its cmake modules (nor in any other of Qt5's modules, for that matter). So while your hypothesis seems reasonable I don't see where the -lpng would be added by Qt's modules. (FWIW, QtWebKit also has a .pc file, but it doesn't add - lz after -lpng so unless someone reorders the link library order that file cannot be the source of the issue either.) I've asked a more generic question about fully-qualified path conversion to -lfoo on the general ML ("/path/to/libpng.so automatic conversion to -lpng"). R. From robert.maynard at kitware.com Wed Jul 12 14:59:15 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 12 Jul 2017 14:59:15 -0400 Subject: [cmake-developers] [ANNOUNCE] CMake 3.9.0-rc6 is ready for testing Message-ID: I am proud to announce the sixth CMake 3.9 release candidate. https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.9 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.9/release/3.9.html Some of the more significant changes in CMake 3.9 are: * An update to Visual Studio 2015 changed the GenerateDebugInformation linker setting it expects in .vcxproj files. CMake 3.9 has been updated to account for this. * "CUDA" is now supported by the Visual Studio Generators for VS 2010 and above. This complements the existing support by the Makefile Generators and the "Ninja" generator. CUDA 8.0.61 or higher is recommended due to known bugs in the VS integration by earlier versions. * CMake is now aware of the "C++ standards" and "C standards" and their associated meta-features for the following "compiler ids": "Cray", "PGI", and "XL". * The "add_library()" command "IMPORTED" option learned to support Object Libraries. * All "find_" commands now have a "PACKAGE_ROOT" search path group that is first in the search heuristics. If a "find_" command is called from inside a find module, then the CMake variable and environment variable named "_ROOT" are used as prefixes and are the first set of paths to be searched. * The "install(TARGETS)" command learned a new "OBJECTS" option to specify where to install Object Libraries. * The "install(EXPORT)" command learned how to export Object Libraries. * A "BUILD_WITH_INSTALL_NAME_DIR" target property and corresponding "CMAKE_BUILD_WITH_INSTALL_NAME_DIR" variable were added to control whether to use the "INSTALL_NAME_DIR" target property value for binaries in the build tree. This is for macOS "install_name" as "BUILD_WITH_INSTALL_RPATH" is for "RPATH". * A "CUDA_PTX_COMPILATION" target property was added to Object Libraries to support compiling to ".ptx" files instead of host object files. * A new "GoogleTest" module was added to provide the "gtest_add_tests()" function independently of the "FindGTest" module. The function was also updated to support keyword arguments, with functionality expanded to allow a test name prefix and suffix to be specified, the dependency on the source files to be optional and the list of discovered test cases to be returned to the caller. * The "Ninja" generator has loosened the dependencies of object compilation. Object compilation now depends only on custom targets and custom commands associated with libraries on which the object's target depends and no longer depends on the libraries themselves. Source files in dependent targets may now compile without waiting for their targets' dependencies to link. * Interprocedural optimization (IPO) is now supported for GNU and Clang compilers using link time optimization (LTO) flags. See the "INTERPROCEDURAL_OPTIMIZATION" target property and "CheckIPOSupported" module. * The "TARGET_OBJECTS" "generator expression" is now supported by the "add_custom_command()" and "file(GENERATE)" commands. CMake 3.9 Release Notes *********************** Changes made since CMake 3.8 include the following. New Features ============ Languages --------- * "CUDA" is now supported by the Visual Studio Generators for VS 2010 and above. This complements the existing support by the Makefile Generators and the "Ninja" generator. CUDA 8.0.61 or higher is recommended due to known bugs in the VS integration by earlier versions. * CMake is now aware of the "C++ standards" and "C standards" and their associated meta-features for the following "compiler ids": "Cray", "PGI", and "XL". Generators ---------- * Visual Studio Generators for VS 2010 and above learned to support the "ASM_NASM" language when "nasm" is installed. * The "Xcode" generator learned to create Xcode schema files. This is an experimental feature and can be activated by setting the "CMAKE_XCODE_GENERATE_SCHEME" variable to a "TRUE" value. Commands -------- * The "add_library()" command "IMPORTED" option learned to support Object Libraries. * All "find_" commands now have a "PACKAGE_ROOT" search path group that is first in the search heuristics. If a "find_" command is called from inside a find module, then the CMake variable and environment variable named "_ROOT" are used as prefixes and are the first set of paths to be searched. * The "find_library()" command learned to search "libx32" paths when the build targets the "x32" ABI. See the "FIND_LIBRARY_USE_LIBX32_PATHS" global property. * The "include_external_msproject()" command learned to use the "MAP_IMPORTED_CONFIG_" target property to map current configurations to the external configurations. * The "install(TARGETS)" command learned a new "OBJECTS" option to specify where to install Object Libraries. * The "install(EXPORT)" command learned how to export Object Libraries. * The "project()" command learned an optional "DESCRIPTION" parameter to set the "PROJECT_DESCRIPTION" variable. * The "separate_arguments()" command gained a "NATIVE_COMMAND" mode that performs argument separation depending on the host operating system. Variables --------- * A "CMAKE_ANDROID_NDK_DEPRECATED_HEADERS" variable was added for use when Cross Compiling for Android with the NDK to request use of the deprecated headers even when unified headers are available. The default is now to use unified headers if available. * A "CMAKE_AUTOMOC_DEPEND_FILTERS" variable was introduced to allow "CMAKE_AUTOMOC" to extract additional dependency file names for "moc" from the contents of source files. * A "CMAKE_AUTOUIC_SEARCH_PATHS" variable was introduced to allow "CMAKE_AUTOUIC" to search for "foo.ui" in more places than the vicinity of the file including "ui_foo.h". * A "CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX" variable was added to tell the "find_library()" command to search in a "lib" directory before each "lib" directory that would normally be searched. * A "CMAKE_INTERPROCEDURAL_OPTIMIZATION" variable was added to initialize the "INTERPROCEDURAL_OPTIMIZATION" property on all targets. * A "CMAKE__COMPILER_AR" variable was added to hold the path to the GCC/Clang wrapper of "ar". * A "CMAKE__COMPILER_RANLIB" variable was added to hold the path to the GCC/Clang wrapper of "ranlib". * The "CMAKE_SYSROOT_COMPILE" and "CMAKE_SYSROOT_LINK" variables were added to use separate sysroots for compiling and linking. Properties ---------- * A new "AUTOGEN_BUILD_DIR" target property was introduced to set a custom output directory for "AUTOMOC", "AUTOUIC", and "AUTORCC". * A new "AUTOMOC_DEPEND_FILTERS" target property was introduced to allow "AUTOMOC" to extract additional dependency file names for "moc" from the contents of source files. * A new "AUTOUIC_SEARCH_PATHS" target property was introduced to allow "AUTOUIC" to search for "foo.ui" in more places than the vicinity of the file including "ui_foo.h". * Global properties "AUTOGEN_SOURCE_GROUP", "AUTOMOC_SOURCE_GROUP" and "AUTORCC_SOURCE_GROUP" were introduced to allow files generated by "AUTOMOC" or "AUTORCC" to be placed in a "source_group()". * A "BUILD_WITH_INSTALL_NAME_DIR" target property and corresponding "CMAKE_BUILD_WITH_INSTALL_NAME_DIR" variable were added to control whether to use the "INSTALL_NAME_DIR" target property value for binaries in the build tree. This is for macOS "install_name" as "BUILD_WITH_INSTALL_RPATH" is for "RPATH". * A "CUDA_PTX_COMPILATION" target property was added to Object Libraries to support compiling to ".ptx" files instead of host object files. * A "GENERATOR_IS_MULTI_CONFIG" global property was added to determine whether the current generator is a multi-configuration generator (such as Visual Studio Generators or "Xcode"). * The "INTERPROCEDURAL_OPTIMIZATION" target property is now enforced when enabled. CMake will add IPO flags unconditionally or produce an error if it does not know the flags for the current compiler. The project is now responsible to use the "CheckIPOSupported" module to check for IPO support before enabling the target property. See policy "CMP0069". * The "WINDOWS_EXPORT_ALL_SYMBOLS" target property may now be used in combination with explicit ".def" files in order to export all symbols from the object files within a target plus an explicit list of symbols that the linker finds in dependencies (e.g. "msvcrt.lib"). Modules ------- * A "CheckIPOSupported" module was added to help projects check whether interprocedural optimization (IPO) is supported by the current toolchain and CMake version. * The "CMakeFindDependencyMacro" module "find_dependency" macro now forwards all arguments to the underlying "find_package()" call. Existing uses will continue to function as before, but callers can now access the full suite of arguments that "find_package" accepts. * The "FeatureSummary" module "feature_summary()" command now accepts the new "DEFAULT_DESCRIPTION" option that will print the default title for the selected package type. * The "FeatureSummary" module gained a new "FeatureSummary__DESCRIPTION" variable that can be defined for each "" to replace the type name with the specified string whenever the package type is used in an output string by the module. * The "FindDoxygen" module learned to control Doxygen behavior using CMake variables and generate documentation via the newly added "doxygen_add_docs()" function. The Doxygen input file ("Doxyfile") is automatically generated and doxygen is run as part of a custom target. Additional components can be specified to find optional tools: "dot", "mscgen" and "dia". * The "FindMPI" module now provides imported targets. * The "FindProtobuf" module "protobuf_generate_cpp()" command gained an "EXPORT_MACRO" option to specify the name of a DLL export markup macro. * The "FindProtobuf" module now supports usage of static libraries for Unix via a new "Protobuf_USE_STATIC_LIBS" input variable. * The "FindProtobuf" module now provides imported targets when the libraries are found. * A new "GoogleTest" module was added to provide the "gtest_add_tests()" function independently of the "FindGTest" module. The function was also updated to support keyword arguments, with functionality expanded to allow a test name prefix and suffix to be specified, the dependency on the source files to be optional and the list of discovered test cases to be returned to the caller. CTest ----- * The "ctest_submit()" command gained a "HTTPHEADER" option to specify custom headers to send during submission. * The "ctest(1)" executable gained new options which allow the developer to disable automatically adding tests to the test set to satisfy fixture dependencies. "-FS" prevents adding setup tests for fixtures matching the provided regular expression, "-FC" prevents adding cleanup tests for matching fixtures and "-FA" prevents adding any test for matching fixtures. * A "DISABLED" test property was added to mark tests that are configured but explicitly disabled so they do not run. CPack ----- * The "CPackArchive" module learned to modify the filename per- component. See the "CPACK_ARCHIVE_FILE_NAME" variable and its per- component version "CPACK_ARCHIVE__FILE_NAME". * The "CPackComponent" module "cpack_add_component()" command gained a new "PLIST " option to specify the "pkgbuild" "-- component-plist" argument when using the "productbuild" generator. * The "CPackIFW" module "cpack_ifw_configure_component()" and "cpack_ifw_configure_component_group()" commands gained internationalization support for "DISPLAY_NAME" and "DESCRIPTION" options. * The "CPackIFW" module learned the new hint "CPACK_IFW_ROOT" variable for finding the QtIFW tool suite installed in a non- standard place. * The "CPackProductBuild" module gained a new "CPACK_PRODUCTBUILD_RESOURCES_DIR" variable to specify resources to be copied into the "Resources" directory. * The "CPackRPM" module learned to modify the "debuginfo" package name. See the "CPACK_RPM_DEBUGINFO_FILE_NAME" variable. * The "CPackWIX" module patching system now has the ability to set additional attributes. This can be done by specifying attributes with the "CPackWiXFragment" XML tag after the "Id" attribute. See the "CPACK_WIX_PATCH_FILE" variable. * The CPack WIX generator implemented a new "CPACK_WIX_ROOT_FOLDER_ID" variable which allows using a custom root folder ID instead of the default "ProgramFilesFolder" / "ProgramFiles64Folder". Other ----- * Interprocedural optimization (IPO) is now supported for GNU and Clang compilers using link time optimization (LTO) flags. See the "INTERPROCEDURAL_OPTIMIZATION" target property and "CheckIPOSupported" module. * The "TARGET_OBJECTS" "generator expression" is now supported by the "add_custom_command()" and "file(GENERATE)" commands. * Two new informational generator expressions to retrieve Apple Bundle directories have been added. The first one "$" outputs the full path to the Bundle directory, the other one "$" outputs the full path to the "Contents" directory of macOS Bundles and App Bundles. For all other bundle types and SDKs it is identical with "$". The new expressions are helpful to query Bundle locations independent of the different Bundle types and layouts on macOS and iOS. Deprecated and Removed Features =============================== * An explicit deprecation diagnostic was added for policies "CMP0036" and below. The "cmake-policies(7)" manual explains that the OLD behaviors of all policies are deprecated and that projects should always port to the NEW behaviors as soon as possible. * The "Visual Studio 8 2005" generator is now deprecated and will be removed in a future version of CMake. * The "Visual Studio 7 .NET 2003" generator has been removed. * The "Xcode" generator dropped support for Xcode versions older than 3. * The "FindDoxygen" module has deprecated several variables. * The version of curl bundled with CMake no longer accepts URLs of the form "file://c:/..." on Windows due to a change in upstream curl 7.52. Use the form "file:///c:/..." instead to work on all versions. Other Changes ============= * When using "AUTOMOC", CMake now scans for the presence of the "Q_PLUGIN_METADATA" macro and reruns moc when the file from the macro's "FILE" argument changes. * When "AUTOMOC" detects an include statement of the form "#include "moc_.cpp"" the search for the respective header file now looks in the "INCLUDE_DIRECTORIES" of the target as well. * When running tests, CTest learned to treat skipped tests (using the "SKIP_RETURN_CODE" property) the same as tests with the new "DISABLED" property. Due to this change, CTest will not indicate failure when all tests are either skipped or pass. * The "Ninja" generator has loosened the dependencies of object compilation. Object compilation now depends only on custom targets and custom commands associated with libraries on which the object's target depends and no longer depends on the libraries themselves. Source files in dependent targets may now compile without waiting for their targets' dependencies to link. * On macOS, the default application bundle "Info.plist" file now enables Hi-DPI support. * On macOS, "RPATH" settings such as "BUILD_WITH_INSTALL_RPATH" no longer affect the "install_name" field. See policy "CMP0068". ---------------------------------------------------------------------------- Changes made since CMake 3.9.0-rc5: Brad King (11): VS: Fix GenerateDebugInformation values for v140 and v141 toolsets Autogen: Skip generated files for compatibility with CMake 3.8 find_package: Restore longer message when config files were considered VS: Choose VS 2017 instance via environment variable bindexplib: Revert support for constants symbols cmFindCommon: Fix typo in PackageName_ROOT path label cmFindCommon: Drop unused FilterPaths method find_*: Honor PATH_SUFFIXES in PackageName_ROOT paths VS: Add SolutionGuid to generated .sln files Android: Link to android_support with c++_shared CMake 3.9.0-rc6 Gregor Jasny (1): Xcode: Use correct Object Library paths for cross-SDK builds Ian Hojnicki (3): VS: Split link flag table between v140 and v141 toolsets VS: Fix GenerateDebugInformation flag map text for v141 toolsets VS: Add v140 and v141 flag table entries for /DEBUG:NONE and /DEBUG:FULL J?r?me Duval (1): curl: Fix build on Haiku Olender, Sebastian D (1): VS: Fix support for '/guard:cf' linker flag Robert Dailey (2): FindDoxygen: Use a stable reference to the location of global resources FindDoxygen: Create DOXYGEN_OUTPUT_DIRECTORY if it doesn't exist Sebastian Holtermann (3): Autogen: Check .moc header name against SKIP list Autogen: Continue search for FOO_p.h when FOO.h was found Autogen: Skip included files on demand From rcdailey.lists at gmail.com Thu Jul 13 16:19:04 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Thu, 13 Jul 2017 15:19:04 -0500 Subject: [cmake-developers] Using USES_TERMINAL in ExternalProject.cmake Message-ID: In my own personal usage of add_custom_target() and add_custom_command(), I use USES_TERMINAL so that stdout and stderr from commands that are actively running get output in more real-time. I've only tested this using the Ninja generator, and seems to improve output behavior. Without it, I notice that commands that take a long time to complete result in a large window of silence. When the command completes, all of its output (sometimes thousands of lines) gets spit out all at once. This makes things weird, especially for things like download progress. I noticed that ExternalProject_Add() has this same issue when run from Ninja. I do not see real-time output of the progress. Would it work to set USES_TERMINAL for most (if not all) custom commands and targets in ExternalProject.cmake? From nilsgladitz at gmail.com Thu Jul 13 16:30:00 2017 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 13 Jul 2017 22:30:00 +0200 Subject: [cmake-developers] Using USES_TERMINAL in ExternalProject.cmake In-Reply-To: References: Message-ID: <5d8a55ea-c48c-2a0c-6d93-6aea1b1724c8@gmail.com> On 13.07.2017 22:19, Robert Dailey wrote: > I noticed that ExternalProject_Add() has this same issue when run from > Ninja. I do not see real-time output of the progress. Would it work to > set USES_TERMINAL for most (if not all) custom commands and targets in > ExternalProject.cmake? See the USES_TERMINAL_* options in https://cmake.org/cmake/help/latest/module/ExternalProject.html (since 3.4) but beware that there can be only one job in the console pool at a time so this might also reduce parallelization. Nils From comicfans44 at gmail.com Sat Jul 15 20:37:05 2017 From: comicfans44 at gmail.com (comic fans) Date: Sun, 16 Jul 2017 08:37:05 +0800 Subject: [cmake-developers] can ctest script using CMAKE_CFG_INTDIR ? In-Reply-To: References: Message-ID: Thank you for explanation, I'm trying to makes this generator to pass more test, but found test script didn't work well with multi-config generator. as you pointed, CMAKE_CFG_INTDIR didn't work in ctest so I need to find another way to make my generator pass test. recent commits shows that QtAutogen is moving to create suffixed files and folders for different config, but with this commit, my generator test failed on Qt5Autogen as following: Target "rccDepends" has source files which vary by configuration. This is not supported by the "Fastbuild" generator. Config "Debug": /working/CMake/Tests/QtAutogen/rccDepends/main.cpp /working/CMake/fastbuild/Tests/Qt5Autogen/rccDepends/res1.qrc /working/CMake/fastbuild/Tests/Qt5Autogen/rccDepends/res2.qrc /working/CMake/fastbuild/Tests/Qt5Autogen/rccDepends/rccDepends_autogen/EJRQKI7XPS/qrc_res1_Debug.cpp /working/CMake/fastbuild/Tests/Qt5Autogen/rccDepends/rccDepends_autogen/EJRQKI7XPS/qrc_res2_Debug.cpp Config "Release": /working/CMake/Tests/QtAutogen/rccDepends/main.cpp /working/CMake/fastbuild/Tests/Qt5Autogen/rccDepends/res1.qrc /working/CMake/fastbuild/Tests/Qt5Autogen/rccDepends/res2.qrc /working/CMake/fastbuild/Tests/Qt5Autogen/rccDepends/rccDepends_autogen/EJRQKI7XPS/qrc_res1_Release.cpp /working/CMake/fastbuild/Tests/Qt5Autogen/rccDepends/rccDepends_autogen/EJRQKI7XPS/qrc_res2_Release.cpp How should I make my generator compatible with this ? or this feature didn't complete ,I should wait it complete ? On Thu, Jul 6, 2017 at 8:45 PM, Brad King wrote: > On 07/05/2017 07:29 PM, comic fans wrote: >> but when I changed test script as : >> --test-command ${CMAKE_CMAKE_COMMAND} -E compare_files >> ${CMake_SOURCE_DIR}/Tests/TargetName/scripts/hello_world >> ${CMake_BINARY_DIR}/Tests/TargetName/scripts/${CMAKE_CFG_INTDIR}/hello_world) > > CMAKE_CFG_INTDIR expands to a placeholder that the native build tool > will expand to the configuration chosen at build time. It can only > be used in contexts that will be evaluated by the native build tool. > > There are other means of referring to the configuration during testing. > By "ctest script" do you mean "ctest -S somescript.cmake", > "CTestTestfile.cmake", or something else? > > -Brad > From brad.king at kitware.com Mon Jul 17 10:20:41 2017 From: brad.king at kitware.com (Brad King) Date: Mon, 17 Jul 2017 10:20:41 -0400 Subject: [cmake-developers] AUTOGEN per-config sources In-Reply-To: References: Message-ID: On 07/15/2017 08:37 PM, comic fans wrote: > recent commits shows that QtAutogen is moving to create suffixed files > and folders for different config, but with this commit, > my generator test failed on Qt5Autogen as following: > > Target "rccDepends" has source files which vary by configuration. This is > not supported by the "Fastbuild" generator. > > Config "Debug": > > /working/CMake/Tests/QtAutogen/rccDepends/main.cpp > /working/CMake/fastbuild/Tests/Qt5Autogen/rccDepends/res1.qrc > /working/CMake/fastbuild/Tests/Qt5Autogen/rccDepends/res2.qrc > /working/CMake/fastbuild/Tests/Qt5Autogen/rccDepends/rccDepends_autogen/EJRQKI7XPS/qrc_res1_Debug.cpp > /working/CMake/fastbuild/Tests/Qt5Autogen/rccDepends/rccDepends_autogen/EJRQKI7XPS/qrc_res2_Debug.cpp > > Config "Release": > > /working/CMake/Tests/QtAutogen/rccDepends/main.cpp > /working/CMake/fastbuild/Tests/Qt5Autogen/rccDepends/res1.qrc > /working/CMake/fastbuild/Tests/Qt5Autogen/rccDepends/res2.qrc > /working/CMake/fastbuild/Tests/Qt5Autogen/rccDepends/rccDepends_autogen/EJRQKI7XPS/qrc_res1_Release.cpp > /working/CMake/fastbuild/Tests/Qt5Autogen/rccDepends/rccDepends_autogen/EJRQKI7XPS/qrc_res2_Release.cpp > > How should I make my generator compatible with this ? or this feature > didn't complete ,I should wait it complete ? The goal for Qt AUTOGEN features is to have the generated files use per-config locations in multi-config generators. However, our multi-config generators don't all fully support per-config sources yet. Your new generator should do so if possible. See GetAllConfigSources in cmGeneratorTarget. Sebastian, FYI comic fans is working on a new multi-config generator. -Brad From seblist at xwmw.org Tue Jul 18 05:03:27 2017 From: seblist at xwmw.org (Sebastian Holtermann) Date: Tue, 18 Jul 2017 11:03:27 +0200 Subject: [cmake-developers] AUTOGEN per-config sources In-Reply-To: References: Message-ID: <9320d6ee-691c-7fcd-cf9b-55e71239aefc@xwmw.org> Am 17.07.2017 um 16:20 schrieb Brad King: > On 07/15/2017 08:37 PM, comic fans wrote: >> recent commits shows that QtAutogen is moving to create suffixed files >> and folders for different config, but with this commit, >> my generator test failed on Qt5Autogen as following: >> >> Target "rccDepends" has source files which vary by configuration. This is >> not supported by the "Fastbuild" generator. >> >> Config "Debug": >> >> /working/CMake/Tests/QtAutogen/rccDepends/main.cpp >> /working/CMake/fastbuild/Tests/Qt5Autogen/rccDepends/res1.qrc >> /working/CMake/fastbuild/Tests/Qt5Autogen/rccDepends/res2.qrc >> /working/CMake/fastbuild/Tests/Qt5Autogen/rccDepends/rccDepends_autogen/EJRQKI7XPS/qrc_res1_Debug.cpp >> /working/CMake/fastbuild/Tests/Qt5Autogen/rccDepends/rccDepends_autogen/EJRQKI7XPS/qrc_res2_Debug.cpp >> >> Config "Release": >> >> /working/CMake/Tests/QtAutogen/rccDepends/main.cpp >> /working/CMake/fastbuild/Tests/Qt5Autogen/rccDepends/res1.qrc >> /working/CMake/fastbuild/Tests/Qt5Autogen/rccDepends/res2.qrc >> /working/CMake/fastbuild/Tests/Qt5Autogen/rccDepends/rccDepends_autogen/EJRQKI7XPS/qrc_res1_Release.cpp >> /working/CMake/fastbuild/Tests/Qt5Autogen/rccDepends/rccDepends_autogen/EJRQKI7XPS/qrc_res2_Release.cpp >> >> How should I make my generator compatible with this ? or this feature >> didn't complete ,I should wait it complete ? > > The goal for Qt AUTOGEN features is to have the generated files use > per-config locations in multi-config generators. However, our > multi-config generators don't all fully support per-config sources yet. > Your new generator should do so if possible. See GetAllConfigSources > in cmGeneratorTarget. > > Sebastian, FYI comic fans is working on a new multi-config generator. It might be better to whitelist generators in AUTOGEN to use per-config sources than blacklisting them. I'll have another look at it later. -Sebastian From robert.maynard at kitware.com Tue Jul 18 14:28:31 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 18 Jul 2017 14:28:31 -0400 Subject: [cmake-developers] [ANNOUNCE] CMake 3.9.0 available for download Message-ID: I am proud to announce that CMake 3.9.0 is now available for download at: https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.9 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.9/release/3.9.html Some of the more significant changes in CMake 3.9 are: * The "Visual Studio 14 2015" generator has been taught about a change to the "v140" toolset made by a VS 2015 update. VS changed the set of values it understands for the "GenerateDebugInformation" linker setting that produces the "-DEBUG" linker flag variants. * "CUDA" is now supported by the Visual Studio Generators for VS 2010 and above. This complements the existing support by the Makefile Generators and the "Ninja" generator. CUDA 8.0.61 or higher is recommended due to known bugs in the VS integration by earlier versions. * CMake is now aware of the "C++ standards" and "C standards" and their associated meta-features for the following "compiler ids": "Cray", "PGI", and "XL". * The "add_library()" command "IMPORTED" option learned to support Object Libraries. * All "find_" commands now have a "PACKAGE_ROOT" search path group that is first in the search heuristics. If a "find_" command is called from inside a find module, then the CMake variable and environment variable named "_ROOT" are used as prefixes and are the first set of paths to be searched. * The "install(TARGETS)" command learned a new "OBJECTS" option to specify where to install Object Libraries. * The "install(EXPORT)" command learned how to export Object Libraries. * A "BUILD_WITH_INSTALL_NAME_DIR" target property and corresponding "CMAKE_BUILD_WITH_INSTALL_NAME_DIR" variable were added to control whether to use the "INSTALL_NAME_DIR" target property value for binaries in the build tree. This is for macOS "install_name" as "BUILD_WITH_INSTALL_RPATH" is for "RPATH". * A "CUDA_PTX_COMPILATION" target property was added to Object Libraries to support compiling to ".ptx" files instead of host object files. * A new "GoogleTest" module was added to provide the "gtest_add_tests()" function independently of the "FindGTest" module. The function was also updated to support keyword arguments, with functionality expanded to allow a test name prefix and suffix to be specified, the dependency on the source files to be optional and the list of discovered test cases to be returned to the caller. * The "Ninja" generator has loosened the dependencies of object compilation. Object compilation now depends only on custom targets and custom commands associated with libraries on which the object's target depends and no longer depends on the libraries themselves. Source files in dependent targets may now compile without waiting for their targets' dependencies to link. * Interprocedural optimization (IPO) is now supported for GNU and Clang compilers using link time optimization (LTO) flags. See the "INTERPROCEDURAL_OPTIMIZATION" target property and "CheckIPOSupported" module. * The "TARGET_OBJECTS" "generator expression" is now supported by the "add_custom_command()" and "file(GENERATE)" commands. CMake 3.9 Release Notes *********************** Changes made since CMake 3.8 include the following. New Features ============ Languages --------- * "CUDA" is now supported by the Visual Studio Generators for VS 2010 and above. This complements the existing support by the Makefile Generators and the "Ninja" generator. CUDA 8.0.61 or higher is recommended due to known bugs in the VS integration by earlier versions. * CMake is now aware of the "C++ standards" and "C standards" and their associated meta-features for the following "compiler ids": "Cray", "PGI", and "XL". Generators ---------- * Visual Studio Generators for VS 2010 and above learned to support the "ASM_NASM" language when "nasm" is installed. * The "Xcode" generator learned to create Xcode schema files. This is an experimental feature and can be activated by setting the "CMAKE_XCODE_GENERATE_SCHEME" variable to a "TRUE" value. * The "Xcode" generator now supports Xcode 9. Commands -------- * The "add_library()" command "IMPORTED" option learned to support Object Libraries. * All "find_" commands now have a "PACKAGE_ROOT" search path group that is first in the search heuristics. If a "find_" command is called from inside a find module, then the CMake variable and environment variable named "_ROOT" are used as prefixes and are the first set of paths to be searched. * The "find_library()" command learned to search "libx32" paths when the build targets the "x32" ABI. See the "FIND_LIBRARY_USE_LIBX32_PATHS" global property. * The "include_external_msproject()" command learned to use the "MAP_IMPORTED_CONFIG_" target property to map current configurations to the external configurations. * The "install(TARGETS)" command learned a new "OBJECTS" option to specify where to install Object Libraries. * The "install(EXPORT)" command learned how to export Object Libraries. * The "project()" command learned an optional "DESCRIPTION" parameter to set the "PROJECT_DESCRIPTION" variable. * The "separate_arguments()" command gained a "NATIVE_COMMAND" mode that performs argument separation depending on the host operating system. Variables --------- * A "CMAKE_ANDROID_NDK_DEPRECATED_HEADERS" variable was added for use when Cross Compiling for Android with the NDK to request use of the deprecated headers even when unified headers are available. The default is now to use unified headers if available. * A "CMAKE_AUTOMOC_DEPEND_FILTERS" variable was introduced to allow "CMAKE_AUTOMOC" to extract additional dependency file names for "moc" from the contents of source files. * A "CMAKE_AUTOUIC_SEARCH_PATHS" variable was introduced to allow "CMAKE_AUTOUIC" to search for "foo.ui" in more places than the vicinity of the file including "ui_foo.h". * A "CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX" variable was added to tell the "find_library()" command to search in a "lib" directory before each "lib" directory that would normally be searched. * A "CMAKE_INTERPROCEDURAL_OPTIMIZATION" variable was added to initialize the "INTERPROCEDURAL_OPTIMIZATION" property on all targets. * A "CMAKE__COMPILER_AR" variable was added to hold the path to the GCC/Clang wrapper of "ar". * A "CMAKE__COMPILER_RANLIB" variable was added to hold the path to the GCC/Clang wrapper of "ranlib". * The "CMAKE_SYSROOT_COMPILE" and "CMAKE_SYSROOT_LINK" variables were added to use separate sysroots for compiling and linking. Properties ---------- * A new "AUTOGEN_BUILD_DIR" target property was introduced to set a custom output directory for "AUTOMOC", "AUTOUIC", and "AUTORCC". * A new "AUTOMOC_DEPEND_FILTERS" target property was introduced to allow "AUTOMOC" to extract additional dependency file names for "moc" from the contents of source files. * A new "AUTOUIC_SEARCH_PATHS" target property was introduced to allow "AUTOUIC" to search for "foo.ui" in more places than the vicinity of the file including "ui_foo.h". * Global properties "AUTOGEN_SOURCE_GROUP", "AUTOMOC_SOURCE_GROUP" and "AUTORCC_SOURCE_GROUP" were introduced to allow files generated by "AUTOMOC" or "AUTORCC" to be placed in a "source_group()". * A "BUILD_WITH_INSTALL_NAME_DIR" target property and corresponding "CMAKE_BUILD_WITH_INSTALL_NAME_DIR" variable were added to control whether to use the "INSTALL_NAME_DIR" target property value for binaries in the build tree. This is for macOS "install_name" as "BUILD_WITH_INSTALL_RPATH" is for "RPATH". * A "CUDA_PTX_COMPILATION" target property was added to Object Libraries to support compiling to ".ptx" files instead of host object files. * A "GENERATOR_IS_MULTI_CONFIG" global property was added to determine whether the current generator is a multi-configuration generator (such as Visual Studio Generators or "Xcode"). * The "INTERPROCEDURAL_OPTIMIZATION" target property is now enforced when enabled. CMake will add IPO flags unconditionally or produce an error if it does not know the flags for the current compiler. The project is now responsible to use the "CheckIPOSupported" module to check for IPO support before enabling the target property. See policy "CMP0069". * The "WINDOWS_EXPORT_ALL_SYMBOLS" target property may now be used in combination with explicit ".def" files in order to export all symbols from the object files within a target plus an explicit list of symbols that the linker finds in dependencies (e.g. "msvcrt.lib"). Modules ------- * A "CheckIPOSupported" module was added to help projects check whether interprocedural optimization (IPO) is supported by the current toolchain and CMake version. * The "CMakeFindDependencyMacro" module "find_dependency" macro now forwards all arguments to the underlying "find_package()" call. Existing uses will continue to function as before, but callers can now access the full suite of arguments that "find_package" accepts. * The "FeatureSummary" module "feature_summary()" command now accepts the new "DEFAULT_DESCRIPTION" option that will print the default title for the selected package type. * The "FeatureSummary" module gained a new "FeatureSummary__DESCRIPTION" variable that can be defined for each "" to replace the type name with the specified string whenever the package type is used in an output string by the module. * The "FindDoxygen" module learned to control Doxygen behavior using CMake variables and generate documentation via the newly added "doxygen_add_docs()" function. The Doxygen input file ("Doxyfile") is automatically generated and doxygen is run as part of a custom target. Additional components can be specified to find optional tools: "dot", "mscgen" and "dia". * The "FindMPI" module now provides imported targets. * The "FindProtobuf" module "protobuf_generate_cpp()" command gained an "EXPORT_MACRO" option to specify the name of a DLL export markup macro. * The "FindProtobuf" module now supports usage of static libraries for Unix via a new "Protobuf_USE_STATIC_LIBS" input variable. * The "FindProtobuf" module now provides imported targets when the libraries are found. * A new "GoogleTest" module was added to provide the "gtest_add_tests()" function independently of the "FindGTest" module. The function was also updated to support keyword arguments, with functionality expanded to allow a test name prefix and suffix to be specified, the dependency on the source files to be optional and the list of discovered test cases to be returned to the caller. CTest ----- * The "ctest_submit()" command gained a "HTTPHEADER" option to specify custom headers to send during submission. * The "ctest(1)" executable gained new options which allow the developer to disable automatically adding tests to the test set to satisfy fixture dependencies. "-FS" prevents adding setup tests for fixtures matching the provided regular expression, "-FC" prevents adding cleanup tests for matching fixtures and "-FA" prevents adding any test for matching fixtures. * A "DISABLED" test property was added to mark tests that are configured but explicitly disabled so they do not run. CPack ----- * The "CPackArchive" module learned to modify the filename per- component. See the "CPACK_ARCHIVE_FILE_NAME" variable and its per- component version "CPACK_ARCHIVE__FILE_NAME". * The "CPackComponent" module "cpack_add_component()" command gained a new "PLIST " option to specify the "pkgbuild" "-- component-plist" argument when using the "productbuild" generator. * The "CPackIFW" module "cpack_ifw_configure_component()" and "cpack_ifw_configure_component_group()" commands gained internationalization support for "DISPLAY_NAME" and "DESCRIPTION" options. * The "CPackIFW" module learned the new hint "CPACK_IFW_ROOT" variable for finding the QtIFW tool suite installed in a non- standard place. * The "CPackProductBuild" module gained a new "CPACK_PRODUCTBUILD_RESOURCES_DIR" variable to specify resources to be copied into the "Resources" directory. * The "CPackRPM" module learned to modify the "debuginfo" package name. See the "CPACK_RPM_DEBUGINFO_FILE_NAME" variable. * The "CPackWIX" module patching system now has the ability to set additional attributes. This can be done by specifying attributes with the "CPackWiXFragment" XML tag after the "Id" attribute. See the "CPACK_WIX_PATCH_FILE" variable. * The CPack WIX generator implemented a new "CPACK_WIX_ROOT_FOLDER_ID" variable which allows using a custom root folder ID instead of the default "ProgramFilesFolder" / "ProgramFiles64Folder". Other ----- * Interprocedural optimization (IPO) is now supported for GNU and Clang compilers using link time optimization (LTO) flags. See the "INTERPROCEDURAL_OPTIMIZATION" target property and "CheckIPOSupported" module. * The "TARGET_OBJECTS" "generator expression" is now supported by the "add_custom_command()" and "file(GENERATE)" commands. * Two new informational generator expressions to retrieve Apple Bundle directories have been added. The first one "$" outputs the full path to the Bundle directory, the other one "$" outputs the full path to the "Contents" directory of macOS Bundles and App Bundles. For all other bundle types and SDKs it is identical with "$". The new expressions are helpful to query Bundle locations independent of the different Bundle types and layouts on macOS and iOS. Deprecated and Removed Features =============================== * An explicit deprecation diagnostic was added for policies "CMP0036" and below. The "cmake-policies(7)" manual explains that the OLD behaviors of all policies are deprecated and that projects should always port to the NEW behaviors as soon as possible. * The "Visual Studio 8 2005" generator is now deprecated and will be removed in a future version of CMake. * The "Visual Studio 7 .NET 2003" generator has been removed. * The "Xcode" generator dropped support for Xcode versions older than 3. * The "FindDoxygen" module has deprecated several variables. * The version of curl bundled with CMake no longer accepts URLs of the form "file://c:/..." on Windows due to a change in upstream curl 7.52. Use the form "file:///c:/..." instead to work on all versions. Other Changes ============= * When using "AUTOMOC", CMake now scans for the presence of the "Q_PLUGIN_METADATA" macro and reruns moc when the file from the macro's "FILE" argument changes. * When "AUTOMOC" detects an include statement of the form "#include "moc_.cpp"" the search for the respective header file now looks in the "INCLUDE_DIRECTORIES" of the target as well. * When running tests, CTest learned to treat skipped tests (using the "SKIP_RETURN_CODE" property) the same as tests with the new "DISABLED" property. Due to this change, CTest will not indicate failure when all tests are either skipped or pass. * The "Ninja" generator has loosened the dependencies of object compilation. Object compilation now depends only on custom targets and custom commands associated with libraries on which the object's target depends and no longer depends on the libraries themselves. Source files in dependent targets may now compile without waiting for their targets' dependencies to link. * On macOS, the default application bundle "Info.plist" file now enables Hi-DPI support. * On macOS, "RPATH" settings such as "BUILD_WITH_INSTALL_RPATH" no longer affect the "install_name" field. See policy "CMP0068". * The "Visual Studio 14 2015" generator has been taught about a change to the "v140" toolset made by a VS 2015 update. VS changed the set of values it understands for the "GenerateDebugInformation" linker setting that produces the "-DEBUG" linker flag variants. ---------------------------------------------------------------------------- Changes made since CMake 3.9.0-rc6: Brad King (6): Android: Always add standard include directories last TestDriver: Fix -Wconversion warning Features: Fix support for a list of language standard options Help: Add a 3.9 release note about the VS GenerateDebugInformation update Diagnose object library self-reference CMake 3.9.0 Harry Mallon (1): Xcode: Add "outputPaths" to custom command script build phase Robert Maynard (1): CUDA: CMAKE_EXPORT_COMPILE_COMMANDS now works with CUDA and Ninja From rcdailey.lists at gmail.com Tue Jul 18 16:52:23 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Tue, 18 Jul 2017 15:52:23 -0500 Subject: [cmake-developers] Best way to append "--no-undefined" to shared link flags? In-Reply-To: References: Message-ID: +CMake dev list After googling I came up with this: set( CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -Wl,--no-undefined" ) After talking more with the NDK devs on github though, they seem to indicate this should happen by default (or at least, it does with the CMake that ships with the NDK according to Dan Albert). Does --no-defined get specified by default for other platforms? Or is it just Android that isn't getting it? On Tue, Jul 18, 2017 at 3:38 PM, Robert Dailey wrote: > For only compilers that support it (I guess any clang/gcc compiler?), > I want my shared libs to link with "--no-undefined". What is the best > (most modern) way using CMake 3.9.0 and forward to do this? Is it > still to explicitly set CMAKE_SHARED_LINKER_FLAGS? How does this > impact using toolchain files and cross compiling? I don't want to wipe > out any existing flags, and I'm not sure of the exact syntax the > command line options need to follow. From roman.wueger at gmx.at Wed Jul 19 04:24:36 2017 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Wed, 19 Jul 2017 10:24:36 +0200 Subject: [cmake-developers] CPack install 3rd party shared libraries Message-ID: Hello, I have a project which depends on a self compiled 3rd party project (boost) Boost is here only an example, there are other 3rd party libraries too. If I call the "install" command on the target, then it would be packaged. But how could I add the shared libraries and especially the links for the shared libraries? E.g.: libboost_filesystem.so -> libboost_filesystem.so.1.48.0 libboost_filesystem.so.1.48.0 Thanks in advance Best Regards Roman From roman.wueger at gmx.at Wed Jul 19 07:42:51 2017 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Wed, 19 Jul 2017 13:42:51 +0200 Subject: [cmake-developers] [CMake] CPack install 3rd party shared libraries In-Reply-To: References: Message-ID: <84FEA0E6-A45E-4E79-85AA-84B8A643FD55@gmx.at> The problem with BundleUtilities which Inder is that it doesn't support generator expressions. Maybe I do something wrong? But I need to specify the path to the executable (generator expression) and the paths where to look for dependencies. Right? Please, could you give me a hint? Regards Roman > Am 19.07.2017 um 12:40 schrieb Elvis Stansvik : > > 2017-07-19 10:24 GMT+02:00 Roman W?ger : >> Hello, >> >> I have a project which depends on a self compiled 3rd party project (boost) >> Boost is here only an example, there are other 3rd party libraries too. >> >> If I call the "install" command on the target, then it would be packaged. >> But how could I add the shared libraries and especially the links for the shared libraries? >> >> E.g.: >> libboost_filesystem.so -> libboost_filesystem.so.1.48.0 >> libboost_filesystem.so.1.48.0 >> >> Thanks in advance > > I think fixup_bundle() from BundleUtilities is what you want [1]. > > We're using it to make our Windows and macOS installs standalone, but > (I think) it should work on Linux as well. > > [1] https://cmake.org/cmake/help/v3.8/module/BundleUtilities.html > >> >> Best Regards >> Roman >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake From DLRdave at aol.com Wed Jul 19 10:42:58 2017 From: DLRdave at aol.com (David Cole) Date: Wed, 19 Jul 2017 10:42:58 -0400 Subject: [cmake-developers] [CMake] CPack install 3rd party shared libraries In-Reply-To: References: <84FEA0E6-A45E-4E79-85AA-84B8A643FD55@gmx.at> Message-ID: Very nice example. Does CMake have a place to put examples like VTK does...? If so, where is it? And if not, it would be super useful to start one somewhere "official." However, one word of caution on the example. I know it was targeted at Linux, and perhaps for a very simple case it's proper, but using an unconditional "local" for everything in a gp_resolved_file_type_override would not be something you'd want to do in general, especially on Windows. You would end up with probably on the order of a hundred (or maybe nowadays even a few hundred) DLLs from the Windows system directories inside your bundle. Almost certainly not what you intended. Cheers, David C. On Wed, Jul 19, 2017 at 9:57 AM, Elvis Stansvik wrote: > 2017-07-19 13:42 GMT+02:00 Roman W?ger : >> The problem with BundleUtilities which Inder is that it doesn't support generator expressions. >> >> Maybe I do something wrong? >> But I need to specify the path to the executable (generator expression) and the paths where to look for dependencies. Right? > > You don't need to use a generator to fetch the executable path. You > will know the path, since you installed the executable with > install(..) :) I think most people essentially hardcode the executable > path in their call to fixup_bundle(..). > > If you really want to, I think there is a way to use generator > expressions, and that is to put the fixup_bundle(..) call in a > separate file (say InstallStuff.cmake.in), and then process that file > with file(GENERATE OUTPUT ...) [1] to produce InstallStuff.cmake with > generator expressions evaluated and then use install(SCRIPT > InstallStuff.cmake). But that's much too complicated IMHO, and I would > avoid it. > > I made a minimal example that links against zlib and also the Boost > library you mentioned: > > cmake_minimum_required(VERSION 2.8) > > project(bundletest) > > find_package(ZLIB REQUIRED) > find_package(Boost REQUIRED COMPONENTS filesystem) > > add_executable(bundletest main.cpp) > > target_include_directories(bundletest PRIVATE ${ZLIB_INCLUDE_DIRS} > ${Boost_INCLUDE_DIRS}) > > target_link_libraries(bundletest ${ZLIB_LIBRARIES} ${Boost_LIBRARIES}) > > install(TARGETS bundletest > RUNTIME DESTINATION "bin" > ) > > install(CODE " > function(gp_resolved_file_type_override resolved_file type_var) > set(\${type_var} local PARENT_SCOPE) > endfunction() > include(BundleUtilities) > fixup_bundle(\"\${CMAKE_INSTALL_PREFIX}/bin/bundletest\" \"\" \"\") > " COMPONENT Runtime) > > main.cpp: > > #include > #include > #include > > using namespace boost::filesystem; > > int main (int argc, char *argv[]) { > // Pretend we're using zlib and Boost > deflateInit(0, 0); > std::cout << file_size(argv[1]) << std::endl; > return 0; > } > > The overriding of the gp_resolved_file_type_override was necessary, to > make it treat all libraries as local (otherwise it skips "system" > libraries). See the docs for GetPrerequisites. > > Building/installing this with > > mkdir build > cd build > cmake -DCMAKE_INSTALL_PREFIX=~/bundletest_install .. > make install > > produces: > > /home/estan/bundletest_install > /home/estan/bundletest_install/bin > /home/estan/bundletest_install/bin/bundletest > /home/estan/bundletest_install/bin/libm.so.6 > /home/estan/bundletest_install/bin/libstdc++.so.6 > /home/estan/bundletest_install/bin/libc.so.6 > /home/estan/bundletest_install/bin/libz.so.1 > /home/estan/bundletest_install/bin/libpthread.so.0 > /home/estan/bundletest_install/bin/libboost_system.so.1.58.0 > /home/estan/bundletest_install/bin/libgcc_s.so.1 > /home/estan/bundletest_install/bin/libboost_filesystem.so.1.58.0 > > I did the build on Ubuntu, and tested that it also runs in a clean > Fedora 24 Docker container. > > Hope that helps some. > > Elvis > > [1] https://cmake.org/cmake/help/v3.9/command/file.html > >> >> Please, could you give me a hint? >> >> Regards >> Roman >> >>> Am 19.07.2017 um 12:40 schrieb Elvis Stansvik : >>> >>> 2017-07-19 10:24 GMT+02:00 Roman W?ger : >>>> Hello, >>>> >>>> I have a project which depends on a self compiled 3rd party project (boost) >>>> Boost is here only an example, there are other 3rd party libraries too. >>>> >>>> If I call the "install" command on the target, then it would be packaged. >>>> But how could I add the shared libraries and especially the links for the shared libraries? >>>> >>>> E.g.: >>>> libboost_filesystem.so -> libboost_filesystem.so.1.48.0 >>>> libboost_filesystem.so.1.48.0 >>>> >>>> Thanks in advance >>> >>> I think fixup_bundle() from BundleUtilities is what you want [1]. >>> >>> We're using it to make our Windows and macOS installs standalone, but >>> (I think) it should work on Linux as well. >>> >>> [1] https://cmake.org/cmake/help/v3.8/module/BundleUtilities.html >>> >>>> >>>> Best Regards >>>> Roman >>>> -- >>>> >>>> Powered by www.kitware.com >>>> >>>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >>>> >>>> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >>>> >>>> CMake Support: http://cmake.org/cmake/help/support.html >>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>>> >>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >>>> >>>> Follow this link to subscribe/unsubscribe: >>>> http://public.kitware.com/mailman/listinfo/cmake >> > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From brad.king at kitware.com Thu Jul 20 09:59:46 2017 From: brad.king at kitware.com (Brad King) Date: Thu, 20 Jul 2017 09:59:46 -0400 Subject: [cmake-developers] Best way to append "--no-undefined" to shared link flags? In-Reply-To: References: Message-ID: On 07/18/2017 04:52 PM, Robert Dailey wrote: > set( CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} > -Wl,--no-undefined" ) That's fine, but you can use `string(APPEND)` to shorten the code: string(APPEND CMAKE_SHARED_LINKER_FLAGS " -Wl,--no-undefined") > After talking more with the NDK devs on github though, they seem to > indicate this should happen by default (or at least, it does with the > CMake that ships with the NDK according to Dan Albert). I don't think the NDK build system itself did that back when we first developed CMake's NDK support. It looks like their NDK-provided toolchain does do it by default, but with an option to turn it off. > Does --no-defined get specified by default for other platforms? > Or is it just Android that isn't getting it? CMake doesn't add --no-undefined by default on any platform. -Brad From irwin at beluga.phys.uvic.ca Fri Jul 21 18:23:39 2017 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Fri, 21 Jul 2017 15:23:39 -0700 (PDT) Subject: [cmake-developers] Java language support regression (compared with 3.7.x and 3.8.x) for 3.9.0 Message-ID: I have built CMake-3.9.0 on my Linux (Debian Jessie) platform using the bootstrap method I have always successfully used for other CMake versions (including 3.7.2). For a complex project (PLplot) which uses swig_add_module and swig_link_libraries to implement our Java binding, I get the following error message at the end of that CMake-3.9.0 output. -- Configuring done CMake Error: Error required internal CMake variable not set, cmake may not be built correctly. Missing variable is: CMAKE_Java_CREATE_SHARED_MODULE -- Generating done -- Build files have been written to: /home/software/plplot/HEAD/build_dir I don't get this error message for CMake-3.7.2. Using find and xargs -0 grep I have looked in both 3.7.2 and 3.9.0 source code for any mention of CMAKE_Java_CREATE_SHARED_MODULE, and it just does not exist. By the way, I have tried the following simple project. cmake_minimum_required(VERSION 3.6.2 FATAL_ERROR) project(test_java NONE) enable_language(Java) message(STATUS "CMAKE_Java_CREATE_SHARED_MODULE = ${CMAKE_Java_CREATE_SHARED_MODULE}") (I used 3.6.2 for the minimum version because that is what PLplot uses). That project does confirm that both 3.7.2 and 3.9.0 do not define CMAKE_Java_CREATE_SHARED_MODULE. However, both versions failed to generate the above error so a more complex project such as PLplot that, e.g., swig-generates a Java binding for a C library is needed to show the issue. By the way, inserting the following lines in the PLplot top-level CMakeLists.txt file # Temporary workaround for Java language support issue for # CMake-3.9.0 set(CMAKE_Java_CREATE_SHARED_MODULE "this_command_should_never_be_used") has no bad consequences for cmake-3.7.2, i.e., I can build our Java binding and run all our standard Java examples. However, for the 3.9.0 case, the above change avoids the cmake issue, but there are many JNI-related build errors for our Java binding (although none of them mention "this_command_should_never_be_used"). The only cmake-3.8.0 version I have built previously is one of the release candidates. But that passed all tests at the time including building our Java binding and running our Java examples with success so this appears to be a newly introduced issue for 3.9.0. >From these symptoms, I am pretty sure that language support infrastructure has been upgraded for 3.9.0, but your Java language support has not been consistently upgraded at the same time. If so, the solution is either downgrade your language support infrastructure to be consistent with CMake-3.8.x or to upgrade your Java language support to be consistent with your updated language support for 3.9.0. Once someone has a patch for this issue I would be happy to test it by rebuilding a patched version of CMake-3.9.0 and trying out a build of PLplot with that patched version. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From craig.scott at crascit.com Sat Jul 22 04:46:59 2017 From: craig.scott at crascit.com (Craig Scott) Date: Sat, 22 Jul 2017 18:46:59 +1000 Subject: [cmake-developers] PIE for executables Message-ID: There was recent(ish) work to resolve an issue with ensuring executables are built with PIE enabled for Android, but it would appear that for other platforms, CMake might not be providing the required set of linker flags, missing out on -pie. The end result is that despite having POSITION_INDEPENDENT_CODE set to ON, executables might still be getting built with PIE not enabled. Those who are familiar enough with the various compiler/linker/platform details may want to take a look at the following issue which ties together the information from a few related bug reports: https://gitlab.kitware.com/cmake/cmake/issues/14983 -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Sun Jul 23 10:20:31 2017 From: craig.scott at crascit.com (Craig Scott) Date: Mon, 24 Jul 2017 00:20:31 +1000 Subject: [cmake-developers] Module macros/function names with single leading underscore Message-ID: Devs, A merge request recently highlighted how an undocumented CMake feature may result in macros or functions defined by projects interfering with internal macros or functions defined by CMake modules. Specifically, if a macro or function name starts with a single underscore, it can accidentally be replaced. The scenario goes something like this: 1. CMake module defines an internal macro _aaa() 2. Some other code (project or CMake module) defines another macro or function with the same name but without the leading underscore. So far, no problem. 3. Project code now defines their own macro or function with the same name (i.e. aaa()). The old aaa() macro is renamed to _aaa() and the previous _aaa() macro can no longer be called. The following minimal project demonstrates the scenario, resulting in infinite recursion at the point noted: cmake_minimum_required(VERSION 3.0) project(FooBar) macro(_doFoo) message("Hi from internal doFoo") endmacro() macro(doFoo) message("Hello from first") _doFoo() endmacro() doFoo() macro(doFoo) message("Hello from second") _doFoo() # Infinite recursion triggered here endmacro() doFoo() It turns out that quite a few CMake modules define internal macros or functions with names that have a single leading underscore, which means they are also susceptible to problems like the above. It's probably going to be an uncommon situation, but maybe it's worth considering renaming these single underscore internal macros and functions? There seems to be somewhat of a convention of using two leading underscores in a reasonable number of CMake's modules, so maybe that's something we can consider standardising on. Comments, thoughts, suggestions? -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Tue Jul 25 05:07:46 2017 From: eric.noulard at gmail.com (Eric Noulard) Date: Tue, 25 Jul 2017 11:07:46 +0200 Subject: [cmake-developers] Java language support regression (compared with 3.7.x and 3.8.x) for 3.9.0 In-Reply-To: References: Message-ID: 2017-07-22 0:23 GMT+02:00 Alan W. Irwin : > I have built CMake-3.9.0 on my Linux (Debian Jessie) platform using > the bootstrap method I have always successfully used for other CMake > versions (including 3.7.2). > > For a complex project (PLplot) which uses swig_add_module and > swig_link_libraries to implement our Java binding, I get the following > error message at the end of that CMake-3.9.0 output. > > -- Configuring done > CMake Error: Error required internal CMake variable not set, cmake may > not be built correctly. > Missing variable is: > CMAKE_Java_CREATE_SHARED_MODULE > -- Generating done > -- Build files have been written to: > /home/software/plplot/HEAD/build_dir > > I don't get this error message for CMake-3.7.2. > > Using find and xargs -0 grep I have looked in both 3.7.2 and 3.9.0 > source code for any mention of CMAKE_Java_CREATE_SHARED_MODULE, and it > just does not exist. > > By the way, I have tried the following simple project. > > cmake_minimum_required(VERSION 3.6.2 FATAL_ERROR) > project(test_java NONE) > enable_language(Java) > message(STATUS "CMAKE_Java_CREATE_SHARED_MODULE = > ${CMAKE_Java_CREATE_SHARED_MODULE}") > I'm curious with that. I do currently use UseJava.cmake module https://cmake.org/cmake/help/v3.7/module/UseJava.html for building some java bits in a globally C++ project. I never tried enable_language(Java) what is the status of Java support as a primary language? I tried to find informations about that in the doc and mailing list but didn't find much. Could someone please point me to the appropriate place concerning this? -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Tue Jul 25 07:45:55 2017 From: DLRdave at aol.com (David Cole) Date: Tue, 25 Jul 2017 07:45:55 -0400 Subject: [cmake-developers] Java language support regression (compared with 3.7.x and 3.8.x) for 3.9.0 In-Reply-To: References: Message-ID: Alan, you had said in your original post: "Using find and xargs -0 grep I have looked in both 3.7.2 and 3.9.0 source code for any mention of CMAKE_Java_CREATE_SHARED_MODULE, and it just does not exist." Try searching for "_CREATE_SHARED_MODULE" instead... it's combined in code with the name of the language. Just a hint about how to further the investigation. I'm curious what the result will be, but don't have time right now to dig in on something peripheral to my main to do list. David C. > On Jul 25, 2017, at 5:07 AM, Eric Noulard wrote: > > > > 2017-07-22 0:23 GMT+02:00 Alan W. Irwin : >> I have built CMake-3.9.0 on my Linux (Debian Jessie) platform using >> the bootstrap method I have always successfully used for other CMake >> versions (including 3.7.2). >> >> For a complex project (PLplot) which uses swig_add_module and >> swig_link_libraries to implement our Java binding, I get the following >> error message at the end of that CMake-3.9.0 output. >> >> -- Configuring done >> CMake Error: Error required internal CMake variable not set, cmake may >> not be built correctly. >> Missing variable is: >> CMAKE_Java_CREATE_SHARED_MODULE >> -- Generating done >> -- Build files have been written to: >> /home/software/plplot/HEAD/build_dir >> >> I don't get this error message for CMake-3.7.2. >> >> Using find and xargs -0 grep I have looked in both 3.7.2 and 3.9.0 >> source code for any mention of CMAKE_Java_CREATE_SHARED_MODULE, and it >> just does not exist. >> >> By the way, I have tried the following simple project. >> >> cmake_minimum_required(VERSION 3.6.2 FATAL_ERROR) >> project(test_java NONE) >> enable_language(Java) >> message(STATUS "CMAKE_Java_CREATE_SHARED_MODULE = ${CMAKE_Java_CREATE_SHARED_MODULE}") > > I'm curious with that. > I do currently use UseJava.cmake module > https://cmake.org/cmake/help/v3.7/module/UseJava.html > for building some java bits in a globally C++ project. > > I never tried enable_language(Java) > what is the status of Java support as a primary language? > > I tried to find informations about that in the doc and mailing list but didn't find much. > > Could someone please point me to the appropriate place concerning this? > > > -- > Eric > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From roman.wueger at gmx.at Tue Jul 25 11:43:03 2017 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Tue, 25 Jul 2017 17:43:03 +0200 Subject: [cmake-developers] Signing of DEB and RPM packages Message-ID: Hello, is the signing of DEB packages (debsigs) and RPM packages (rpmsign or rpm --addsign) supported at the moment? Best Regards Roman From ben.boeckel at kitware.com Tue Jul 25 14:40:48 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Tue, 25 Jul 2017 14:40:48 -0400 Subject: [cmake-developers] Signing of DEB and RPM packages In-Reply-To: References: Message-ID: <20170725184048.GA5482@megas.kitware.com> On Tue, Jul 25, 2017 at 17:43:03 +0200, Roman W?ger wrote: > is the signing of DEB packages (debsigs) and RPM packages (rpmsign or > rpm --addsign) supported at the moment? It doesn't appear to be supported right now (no results from grep'ing for "debsig" or "addsign"). --Ben From irwin at beluga.phys.uvic.ca Tue Jul 25 18:00:54 2017 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Tue, 25 Jul 2017 15:00:54 -0700 (PDT) Subject: [cmake-developers] Java language support regression (compared with 3.7.x and 3.8.x) for 3.9.0 In-Reply-To: References: Message-ID: On 2017-07-25 07:45-0400 David Cole wrote: > Alan, you had said in your original post: > > "Using find and xargs -0 grep I have looked in both 3.7.2 and 3.9.0 > source code for any mention of CMAKE_Java_CREATE_SHARED_MODULE, and it > just does not exist." > > Try searching for "_CREATE_SHARED_MODULE" instead... it's combined in code with the name of the language. > > Just a hint about how to further the investigation. I'm curious what the result will be, but don't have time right now to dig in on something peripheral to my main to do list. Hi David: For a v3.8.2 checkout from the release branch, here are the results for such a search with certain specific language results excluded as well as results from cmake.vim which listed a very large line. software at raven> find . -type f -print0 |xargs -0 grep _CREATE_SHARED_MODULE |grep -vE '_(C|CXX|Fortran|CUDA|CSharp|ASM\${ASM_DIALECT})_CREATE_SHARED_MODULE' |grep -v cmake.vim Binary file ./.git/index matches ./Help/manual/cmake-variables.7.rst: /variable/CMAKE_LANG_CREATE_SHARED_MODULE ./Help/variable/CMAKE_LANG_CREATE_SHARED_MODULE.rst:CMAKE__CREATE_SHARED_MODULE ./Source/cmGeneratorTarget.cxx: return "CMAKE_" + lang + "_CREATE_SHARED_MODULE"; ./Source/cmMakefileLibraryTargetGenerator.cxx: linkRuleVar += "_CREATE_SHARED_MODULE"; ./Modules/Platform/Windows-GNU.cmake: set(CMAKE_${lang}_CREATE_SHARED_MODULE ./Modules/Platform/CYGWIN-GNU.cmake: set(CMAKE_${lang}_CREATE_SHARED_MODULE ./Modules/Platform/Windows-MSVC.cmake: set(CMAKE_${lang}_CREATE_SHARED_MODULE ${CMAKE_${lang}_CREATE_SHARED_LIBRARY}) ./Modules/Platform/Windows-Embarcadero.cmake: set(CMAKE_${lang}_CREATE_SHARED_MODULE ./Modules/Platform/Windows-Embarcadero.cmake: ${CMAKE_${lang}_CREATE_SHARED_MODULE} ./Modules/CMakeAddNewLanguage.txt: CMAKE_(LANG)_CREATE_SHARED_MODULE Here are the corresponding results for v3.9.0 (without the cmake.vim exclusion since that file does not appear to be present in that release). software at raven> find . -type f -print0 |xargs -0 grep _CREATE_SHARED_MODULE |grep -vE '_(C|CXX|Fortran|CUDA|CSharp|ASM\${ASM_DIALECT})_CREATE_SHARED_MODULE' Binary file ./.git/index matches ./Help/manual/cmake-variables.7.rst: /variable/CMAKE_LANG_CREATE_SHARED_MODULE ./Help/variable/CMAKE_LANG_CREATE_SHARED_MODULE.rst:CMAKE__CREATE_SHARED_MODULE ./Source/cmGeneratorTarget.cxx: return "CMAKE_" + lang + "_CREATE_SHARED_MODULE"; ./Source/cmMakefileLibraryTargetGenerator.cxx: linkRuleVar += "_CREATE_SHARED_MODULE"; ./Modules/Platform/Windows-GNU.cmake: set(CMAKE_${lang}_CREATE_SHARED_MODULE ./Modules/Platform/CYGWIN-GNU.cmake: set(CMAKE_${lang}_CREATE_SHARED_MODULE ./Modules/Platform/Windows-MSVC.cmake: set(CMAKE_${lang}_CREATE_SHARED_MODULE ${CMAKE_${lang}_CREATE_SHARED_LIBRARY}) ./Modules/Platform/Windows-Embarcadero.cmake: set(CMAKE_${lang}_CREATE_SHARED_MODULE ./Modules/Platform/Windows-Embarcadero.cmake: ${CMAKE_${lang}_CREATE_SHARED_MODULE} ./Modules/Platform/Windows-PGI.cmake: set(CMAKE_${lang}_CREATE_SHARED_MODULE "${CMAKE_${lang}_CREATE_SHARED_LIBRARY}") ./Modules/CMakeAddNewLanguage.txt: CMAKE_(LANG)_CREATE_SHARED_MODULE I don't spot any differences between (working) CMake-3.8.x and (non-working) CMake-3.9.0 except for some new Windows-PGI support which is not relevant to this problem. The error message I got was -- Configuring done CMake Error: Error required internal CMake variable not set, cmake may not be built correctly. Missing variable is: CMAKE_Java_CREATE_SHARED_MODULE Further finding and grepping found the function (in Source/cmMakefile.cxx) that emitted that error message which is defined as follows: const char* cmMakefile::GetRequiredDefinition(const std::string& name) const { const char* ret = this->GetDefinition(name); if (!ret) { cmSystemTools::Error("Error required internal CMake variable not " "set, cmake may not be built correctly.\n", "Missing variable is:\n", name.c_str()); return ""; } return ret; } A further check software at raven> find . -type f -print0 |xargs -0 grep GetRequiredDefinition |wc -l 52 showed ~50 calls of that function, and I don't know which one of those calls is generating this error message for 3.9.0 but not for a release candidate for 3.8.0 (nor for 3.7.2). But presumably that call is somewhere down the call stack from the two mentions of _CREATE_SHARED_MODULE shown above that are in Source. I was hoping some CMake developer here could remember a fairly recent language support infrastructure change in the run-up to 3.9.0 that is likely causing this issue, and better yet could immediately think of the Java language support changes that would need to be made to be consistent with that hypothesized language support infrastructure change. But if nobody gets back to me on that question soon, then I will go ahead and do a git bisect to help find the commit where the Java language support issue first showed up. (I have been reluctant to spend the fairly substantial time to do that git bisect up to now because I was fairly confident someone would respond on that particular hypothesis, and most of my time right now is consumed with dealing with some late release-cycle issues with PLplot.) Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From irwin at beluga.phys.uvic.ca Tue Jul 25 20:48:46 2017 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Tue, 25 Jul 2017 17:48:46 -0700 (PDT) Subject: [cmake-developers] Java language support regression (compared with 3.7.x and 3.8.x) for 3.9.0 In-Reply-To: References: Message-ID: On 2017-07-25 15:00-0700 Alan W. Irwin wrote: > I was hoping some CMake developer here could remember a fairly recent > language support infrastructure change in the run-up to 3.9.0 that is > likely causing this issue, and better yet could immediately think of > the Java language support changes that would need to be made to be > consistent with that hypothesized language support infrastructure > change. But if nobody gets back to me on that question soon, then I > will go ahead and do a git bisect to help find the commit where the > Java language support issue first showed up. Oops. I discovered during the initial stages of that git bisect process that 3.8.0-rc4 is bad while 3.7.2 is good when using the latest git master branch version of PLplot. That result surprised me (since I do recall testing 3.8.0-rc4/ without issues), So my testing of 3.8.0-rc4 may not have included java or some PLplot change between that test and now may be affecting this good/bad result (although I think that is fairly unlikely because I don't recall any specific java-related PLplot changes during that period), Anyhow, I am now bisecting between CMake 3.7.2 and 3.8.0-rc4 using a consistent PLplot version (the tip of our master branch) that is quite well tested for CMake-3.7.2. And if anyone here is attempting to remember relevant language support changes, you should be thinking about the period between 3.7.2 and 3.8.0-rc4. More later on those git bisect results when that process is completed. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From irwin at beluga.phys.uvic.ca Wed Jul 26 06:02:56 2017 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Wed, 26 Jul 2017 03:02:56 -0700 (PDT) Subject: [cmake-developers] Java language support regression (compared with 3.7.x and 3.8.x) for 3.9.0 In-Reply-To: References: Message-ID: On 2017-07-25 17:48-0700 Alan W. Irwin wrote: > More later on those git bisect results when that process is completed. As per usual, git bisect (along with ccache to speed up the process by a noticable amount especially in the last 5 steps or so) is awesome. Here is what it found: 62c4cb4b6f0cdb2be2729362133f850d6fe96c20 is the first bad commit commit 62c4cb4b6f0cdb2be2729362133f850d6fe96c20 Author: caryoscelus Date: Mon Nov 28 21:46:41 2016 +0300 UseSWIG: Record generated java files as custom command outputs When another target depends on the generated files CMake must know which custom command generates them in order to hook up the dependency properly. We already do this for Python. Add the Java files too. :040000 040000 0ba5ac99776eb3c196dfe7639dcf6c47711cd204 135152a2f7229d2a2f63cded6617c5b30f40e9d8 M Modules software at raven> git describe v3.7.0-651-g62c4cb4 The file differences introduced by that change were quite small: software at raven> git diff 62c4cb4b6f0^ 62c4cb4b6f0 diff --git a/Modules/UseSWIG.cmake b/Modules/UseSWIG.cmake index c5912f8..651f9f1 100644 --- a/Modules/UseSWIG.cmake +++ b/Modules/UseSWIG.cmake @@ -57,7 +57,8 @@ set(SWIG_CXX_EXTENSION "cxx") set(SWIG_EXTRA_LIBRARIES "") -set(SWIG_PYTHON_EXTRA_FILE_EXTENSION "py") +set(SWIG_PYTHON_EXTRA_FILE_EXTENSIONS ".py") +set(SWIG_JAVA_EXTRA_FILE_EXTENSIONS ".java" "JNI.java") # # For given swig module initialize variables associated with it @@ -123,9 +124,9 @@ macro(SWIG_GET_EXTRA_OUTPUT_FILES language outfiles generatedpath infile) endif () endif() - foreach(it ${SWIG_${language}_EXTRA_FILE_EXTENSION}) + foreach(it ${SWIG_${language}_EXTRA_FILE_EXTENSIONS}) set(${outfiles} ${${outfiles}} - "${generatedpath}/${SWIG_GET_EXTRA_OUTPUT_FILES_module_basename}.${it}") + "${generatedpath}/${SWIG_GET_EXTRA_OUTPUT_FILES_module_basename}${it}") endforeach() endmacro() UseSWIG.cmake is a complex beast, and I frankly don't understand it. However, for CMake-3.9.0 I tried simply commenting out set(SWIG_JAVA_EXTRA_FILE_EXTENSIONS ".java" "JNI.java") in the installed version of UseSWIG.cmake and that workaround completely solved the CMake-time issue for PLplot! Furthermore, when I built our test_diff_psc target (which exercises our ~30 standard examples written in ~10 different computer languages and compares the generated PostScript plot results for corresponding examples in each language, the Java part of that test was perfect, i.e., each of its standard examples written in Java produced the exact same result as the corresponding standard example written in C. To help with finding a real fix for this issue rather than the above workaround, I have finally came up with a simple test project that demonstrates the issue. ____________________________________________________ cmake_minimum_required(VERSION 3.6.2 FATAL_ERROR) project(test_java C) find_package(SWIG) include(UseSWIG) enable_language(Java) # As a simple test of missing Java language support variables try and # configure a build of a Java module or library from an empty *.i file file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/test_java.i "") swig_add_library(test_java TYPE MODULE LANGUAGE java SOURCES ${CMAKE_CURRENT_BINARY_DIR}/test_java.i) ____________________________________________________ I suggest this test project should be used as a template (possibly with several other languages substituted for Java, NONE substituted for C, and TYPE SHARED substituted for MODULE). Anyhow, here is the cmake command output for this project with unpatched 3.9.0 -- The C compiler identification is GNU 4.9.2 -- Check for working C compiler: /usr/lib/ccache/cc -- Check for working C compiler: /usr/lib/ccache/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Found SWIG: /usr/bin/swig2.0 (found version "2.0.12") -- Configuring done CMake Error: Error required internal CMake variable not set, cmake may not be built correctly. Missing variable is: CMAKE_Java_CREATE_SHARED_MODULE -- Generating done -- Build files have been written to: /home/software/plplot/HEAD/build_dir If the CMake-3.9.0 installed UseSWIG.cmake file is patched (by commenting out the line in that file, set(SWIG_JAVA_EXTRA_FILE_EXTENSIONS ".java" "JNI.java") ), then the initial cmake output is the same, but the final few lines are -- Found SWIG: /usr/bin/swig2.0 (found version "2.0.12") -- Configuring done -- Generating done -- Build files have been written to: /home/software/plplot/HEAD/build_dir So from these two different results, the conclusion is the above simple project file recreates the bad PLplot results for unpatched CMake-3.9.0 and the good PLplot results for patched 3.9.0. Nevertheless, that patch is not a fix but simply a workaround. Therefore, deeper analysis is needed by someone who really understands why that one line generates a check for the existence of the CMAKE_Java_CREATE_SHARED_MODULE (or CMAKE_Java_CREATE_SHARED_LIBRARY if the project builds swig-generated libraries rather than modules). And if that line is commented out that check does not occur for both the simple project and PLplot project, and, in the PLplot case, perfect results are created at run time even though the CMAKE_Java_CREATE_SHARED_MODULE variable is completely missing. In sum, I have whittled down the demonstration of the issue to a simple test project which generates the problem or not depending on the existence of one line in UseSWIG.cmake. And I hope these much more definite and easy to confirm results will inspire a quick resolution for this issue. But if timely resolution is not possible, then I plan to generate a new bug on your bugtracker with the above simple project as an illustration, and let you guys sort it out as your time permits. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From irwin at beluga.phys.uvic.ca Wed Jul 26 06:32:00 2017 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Wed, 26 Jul 2017 03:32:00 -0700 (PDT) Subject: [cmake-developers] Java language support regression (compared with 3.7.x and 3.8.x) for 3.9.0 In-Reply-To: References: Message-ID: Here is a spin-off topic from this thread which I believe may be of general interest. Bill Hoffman contacted me off list about the possibility of testing cmake with a build of a rapidly changing CMake corresponding to the tip of your release branch or possibly one of your development branches AND a corresponding build of a slowly changing PLplot (say change it once per release of PLplot) for each such CMake version. That is a good idea because the PLplot build is fast. For example, the build of the "all" target (including all our standard examples for our supported compiled languages) was completed in only 1 minute 40 seconds (with the aid of ccache) in a recent "make all" test. Even more importantly despite this quick build, the CMake-based build system for PLplot (which we have been developing for the last decade) is quite complex. That is, that build system has to find many soft dependencies of PLplot (almost entirely generated by our various optional device drivers), configure the build of our ~5 libraries, configure the build of the PLplot bindings for our ~10 supported computer languages, configure the build of ~30 standard examples written in each of our supported computer languages for the subset of those languages which are compiled, configure the build for ~15 PLplot device drivers (typically configured as shared objects or DLL's that are dynamically loaded by the core PLplot library if/when needed but another configuration is also possible where the device code is compiled directly into our core library), and configure many separate test targets as well as ctest examples. Because of these excellent PLplot project characteristics for CMake testing purposes, Alex Neundorf set up a combined CMake build and PLplot build test nearly a decade ago, but I assume that no longer exists (although I have asked Bill to search for it, and maybe Alex can comment as well on that CMake history back near the time when the earth was still cooling. :-) ). In any case, the ctest and dashboard server facilities we have now are much better than they were a decade ago, and I am consulting with Bill about the best way to use those facilities properly to set up a new version of Alex's test. And when that nightly test (currently in the very early planning stages) consisting of a CMake build + PLplot build goes live, I think it will be a noticeable improvement in the CMake testing process that will benefit not only the CMake project, but also the PLplot project. Anyhow, Bill and I both hope this test will very much reduce or eliminate instances like the present one where a CMake issue first introduced in 3.8.0 RC's somehow slipped through the cracks of all the normal continuous automatic testing of CMake (see new test suggestion for UseSWIG.cmake in my previous post in this thread). Of course, I am partially responsible for this situation as well because my near-constant testing of PLplot typically occurs for a fixed version of CMake that I rarely have time to change since such change does require a time-consuming build of CMake. Fortunately, the rarety of my CMake version changes used for my PLplot testing will no longer be a problem when the planned continuous integration test goes live so I am really looking forward to that. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________