[Cmake-commits] CMake branch, master, updated. v3.14.0-rc1-110-ga2a903f
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, master has been updated via a2a903fe42f6ef54665135cac54b75d50bcd696c (commit) from 8c4de819449bbb1710b1cc2440357757e5cb757c (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a2a903fe42f6ef54665135cac54b75d50bcd696c commit a2a903fe42f6ef54665135cac54b75d50bcd696c Author: Kitware Robot AuthorDate: Fri Feb 15 00:01:08 2019 -0500 Commit: Kitware Robot CommitDate: Fri Feb 15 00:01:08 2019 -0500 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index 8330dc8..e69ceb9 100644 --- a/Source/CMakeVersion.cmake +++ b/Source/CMakeVersion.cmake @@ -1,5 +1,5 @@ # CMake version number components. set(CMake_VERSION_MAJOR 3) set(CMake_VERSION_MINOR 14) -set(CMake_VERSION_PATCH 20190214) +set(CMake_VERSION_PATCH 20190215) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org https://cmake.org/mailman/listinfo/cmake-commits
Re: [CMake] Redundant linking when modifying shared libraries
Sounds good. The FAQ has a question "Is there a way to skip checking of dependent libraries when compiling?" - perhaps you can add one just before that, something like "Is there a way to reduce the amount of linking when building a large project?".or similar. Thanks again, itay On Thu, Feb 14, 2019 at 11:26 PM Robert Maynard wrote: > > I agree that we should document this property better. > I recommend looking at the CMake wiki ( > https://gitlab.kitware.com/cmake/community/wikis/home ) and thinking > maybe adding a new recipe for `optimizing redundant linking`. > > On Thu, Feb 14, 2019 at 3:11 PM Itay Chamiel wrote: > > > > On Thu, Feb 14, 2019 at 8:08 PM Robert Maynard > > wrote: > > > By default CMake wants to get a correct build 100% of the time. There > > > is nothing to stop people from having functions defined in a .cxx file > > > with no corresponding header, and using manual forward deceleration is > > > used in a consuming library/executable. By setting > > > `LINK_DEPENDS_NO_SHARED` to `True` you will convert what was a link > > > time error ( renaming the function in the .cxx ) to a run time error. > > > > First of all, thanks for the answer - it's good to understand the > > rationale and to know that in our use case we can safely use this > > setting. > > > > On the question of whether to set this as the default, I understand > > your position and I personally disagree - but do not wish to start a > > debate. However I will say that this simple change has, in a common > > case, reduced my build time from 5 minutes to 15 seconds. At the very > > least could you consider steps to make this setting more known and > > accessible? (No one on Stack Overflow knew about it, and I think > > that's saying something.) Perhaps put it in a FAQ, and/or more > > prominently in the documentation. > > > > Kind regards, > > > > itay > > -- > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: > > http://www.cmake.org/Wiki/CMake_FAQ > > > > Kitware offers various services to support the CMake community. For more > > information on each offering, please visit: > > > > CMake Support: http://cmake.org/cmake/help/support.html > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Follow this link to subscribe/unsubscribe: > > https://cmake.org/mailman/listinfo/cmake -- Itay Chamiel, Software Engineer itay.cham...@orcam.com | Office: +972-2-591-7800, ext. 7814 OrCam Technologies www.orcam.com -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Redundant linking when modifying shared libraries
I agree that we should document this property better. I recommend looking at the CMake wiki ( https://gitlab.kitware.com/cmake/community/wikis/home ) and thinking maybe adding a new recipe for `optimizing redundant linking`. On Thu, Feb 14, 2019 at 3:11 PM Itay Chamiel wrote: > > On Thu, Feb 14, 2019 at 8:08 PM Robert Maynard > wrote: > > By default CMake wants to get a correct build 100% of the time. There > > is nothing to stop people from having functions defined in a .cxx file > > with no corresponding header, and using manual forward deceleration is > > used in a consuming library/executable. By setting > > `LINK_DEPENDS_NO_SHARED` to `True` you will convert what was a link > > time error ( renaming the function in the .cxx ) to a run time error. > > First of all, thanks for the answer - it's good to understand the > rationale and to know that in our use case we can safely use this > setting. > > On the question of whether to set this as the default, I understand > your position and I personally disagree - but do not wish to start a > debate. However I will say that this simple change has, in a common > case, reduced my build time from 5 minutes to 15 seconds. At the very > least could you consider steps to make this setting more known and > accessible? (No one on Stack Overflow knew about it, and I think > that's saying something.) Perhaps put it in a FAQ, and/or more > prominently in the documentation. > > Kind regards, > > itay > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Redundant linking when modifying shared libraries
On Thu, Feb 14, 2019 at 8:08 PM Robert Maynard wrote: > By default CMake wants to get a correct build 100% of the time. There > is nothing to stop people from having functions defined in a .cxx file > with no corresponding header, and using manual forward deceleration is > used in a consuming library/executable. By setting > `LINK_DEPENDS_NO_SHARED` to `True` you will convert what was a link > time error ( renaming the function in the .cxx ) to a run time error. First of all, thanks for the answer - it's good to understand the rationale and to know that in our use case we can safely use this setting. On the question of whether to set this as the default, I understand your position and I personally disagree - but do not wish to start a debate. However I will say that this simple change has, in a common case, reduced my build time from 5 minutes to 15 seconds. At the very least could you consider steps to make this setting more known and accessible? (No one on Stack Overflow knew about it, and I think that's saying something.) Perhaps put it in a FAQ, and/or more prominently in the documentation. Kind regards, itay -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Multiple occurrences of a library on linux (ldd)
I might be getting close and the root cause might be related to a
conceptual question that I was saving for later: how transitive
linking should be done!
Returning to the build design: pytorch is compile if not installed in
the system, lib datareader_core consumes pytorch and standalone_gtests
consumes datareader_core
(aka standalone_gtests --> lib_datareader.so --> libc10.so)
Here are the relevant snippets from all relevant cmake files:
***/CMakeLists.txt***
(...)
# pytorch will be compile here
add_subdirectory(external/upstream)
# datareader_core lib will consume torch during its build
ExternalProject_Add(${PROJECT_NAME}_core
DEPENDS pytorch_external
SOURCE_DIR (...)
CMAKE_ARGS (...)
CMAKE_CACHE_ARGS (...)
BUILD_ALWAYS 1
)
# Consumes datareader_core, which consumes pytorch (libc10.so and libcaffe2.so)
ExternalProject_Add(${PROJECT_NAME}_core_test
DEPENDS ${PROJECT_NAME}_core
SOURCE_DIR (...)
CMAKE_ARGS (...)
CMAKE_CACHE_ARGS -DDATAREADER_CORE_ROOT:INTERNAL=${DATAREADER_CORE_ROOT}
-DDATAREADER_CORE_LIBRARYDIR:INTERNAL=${DATAREADER_CORE_LIBRARYDIR}
-DDATAREADER_CORE_INCLUDEDIR:INTERNAL=${DATAREADER_CORE_INCLUDEDIR}
(...)
BUILD_ALWAYS 1
)
***/external/upstream/CMakeLists.txt***
add_subdirectory(pytorch)
/external/upstream/CMakeLists.txt
find_package(Torch QUIET)
if(NOT Torch_FOUND)
message(STATUS "Pytorch not found in the systemm. Looking in the
build environment")
set(
CMAKE_PREFIX_PATH "${EP_BASE}/Source/pytorch_external/torch/share/cmake"
CACHE INTERNAL "Path to Pytorch cmake configs"
FORCE
)
find_package(Torch QUIET)
endif()
if(Torch_FOUND)
add_library(pytorch_external INTERFACE)
else()
message(STATUS "Pytorch could not be located. Building instead")
include(ExternalProject)
ExternalProject_Add(pytorch_external (...)
endif()
***/datareader_src/CMakeLists.txt***
project(datareader_core)
add_library(datareader SHARED ${DATAREADER_SRC})
find_package(Torch REQUIRED)
target_include_directories(datareader PUBLIC
${CMAKE_CURRENT_SOURCE_DIR}/include)
target_link_libraries(datareader PUBLIC ${TORCH_LIBRARIES})
***/datareader_test_src/CMakeLists.txt***
project(datareader_core_test)
enable_testing()
add_executable(standalone_gtests test.cpp)
find_package(GTest REQUIRED)
find_package(Threads REQUIRED)
target_include_directories(standalone_gtests PUBLIC
${DATAREADER_CORE_INCLUDEDIR}
${GOOGLETEST_INCLUDEDIR}
${CMAKE_CURRENT_SOURCE_DIR}/../)
target_link_libraries(standalone_gtests PUBLIC
${TORCH_LIBRARIES}
${DATAREADER}
${GTEST_BOTH_LIBRARIES}
${CMAKE_THREAD_LIBS_INIT}
)
At this point, Pytorch is looked in the system by find_package(Torch),
if not found, it will be cloned and compiled. datareader_core lib
find_package(Torch) and link to it. Lastly, datareader_core_test app
will link to datareader_core lib.
If I ldd libdatareader.so, I can see libc10.so (from pytorch) is
properly linked. However, datareader_core_test compilation will fail
with an undefined reference to symbol inside libc10.so:
/usr/bin/ld: warning: libcaffe2.so, needed by
/home/dev/miniconda3/datareaders_py37/build/stage/datareader/lib/libdatareader.so,
not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libc10.so, needed by
/home/dev/miniconda3/datareaders_py37/build/stage/datareader/lib/libdatareader.so,
not found (try using -rpath or -rpath-link)
/home/dev/miniconda3/datareaders_py37/build/stage/datareader/lib/libdatareader.so:
undefined reference to `c10::Error::Error(c10::SourceLocation,
std::__cxx11::basic_string,
std::allocator > const&)'
collect2: error: ld returned 1 exit status
My understanding was that if datareader_core did
target_link_libraries(datareader PUBLIC ${TORCH_LIBRARIES}), then any
other target that depends on datareader target would be properly
linked to its public dependences libraries.
Where is my mistake? To work this around, I have added
find_package(Torch REQUIRED) and
target_link_libraries(standalone_gtests PUBLIC ${TORCH_LIBRARIES}) to
standalone_gtests, although it doesn't directly consume anything from
pytorch. That change lead to the original issue of having
standalone_gtests having two entries of libc10.so in the ldd output:
one because of the indirect lib datareader dependency (not fond) and
another due tot he direct linking (working)
Am I linking Torch incorrectly to datareader_core or maybe
ExternalProject_Add(datareader_core) hides linking information from
another target inside another
ExternalProject_Add(datareader_core_test)?
I am a bit confused by the explanation at
https://cmake.org/cmake/help/latest/command/target_link_libraries.html
and this build and your help might help solidify the private, public
and interface concepts.
Thanks again
Thiago
On Thu, Feb 14, 2019 at 7:42 AM Thiago Crepaldi wrote:
>
> Thanks, Thompson, I will look into BUILD_RPATH and possibly INSTALL_RPATH.
>
> I just learned about `export LD_DEBUG=files` to debug linking issues
> on linux. It provides more
Re: [CMake] Is there a way to delay "find_package" until link-time when the package is actually needed?
I guess what I would ultimately like to achieve would be a "pre-cmake-configuration" step that just initializes the package registry with the location of each project's build tree and copies the "project-config.cmake" files into each projects build-tree. This would allow it to be found during generation, but it doesn't seem like it works that way. Maybe some sort of "superbuild" pattern would be a better option. On Thu, Feb 14, 2019 at 1:32 PM Eric Noulard wrote: > > > Le jeu. 14 févr. 2019 à 18:57, Timothy Wrona a > écrit : > >> The problem is it is very likely that there are some circular >> dependencies in the build tree -- which is why it was broken up to >> generation of all, then build all, then link all in the first place. >> > > Yes, wrong solution to a real design issue :-) > > >> >> With circular dependencies there's no real way to sort these dependencies >> out without just running generation twice, but the first run will get a >> bunch of errors for missing packages. >> > > I understand the situation, I did face that too in the past. > If there is not too much circular deps you may either break them by > writing (by hand) a bunch of imported target or you can merge in the same > CMake project the sub-projects belonging to the same cycle. > Feasibility depends on the amount of projects (and cycle) you have. > > > > >> >> On Thu, Feb 14, 2019 at 12:38 PM Eric Noulard >> wrote: >> >>> >>> >>> Le jeu. 14 févr. 2019 à 18:22, Timothy Wrona a >>> écrit : >>> I have a collection of interdependent CMake projects (lots of legacy code) that I want to convert to using CMake targets for linking. The code is built in such a way that all projects run cmake generation, then all projects build, then all projects link. I would like to export a CMake target from one of the projects and link to it in another, but the issue is the project I am exporting from runs its cmake generation AFTER the project I am linking the target in. This causes "find_package" to fail because the target has not been exported yet, but realistically the exported target is not needed until link-time. >>> >>> This heavily depends on the target. Modern CMake target convey compile >>> time information as well like compile flags, include directory etc... >>> >>> Can't you re-order the cmake generation order of your projects? >>> If you [ever] have the graph dependency of your projects you may >>> topologically sort them in order to avoid this issue and superbuild them in >>> appropriate order. >>> >>> Is there a way to delay "find_package" to not look for the package until link-time? >>> >>> I don't think so. >>> >>> At link-time the package will have been exported already and if "find_package" was not called until then, it would be found successfully and the target could be pulled in and linked to. >>> >>> But the build compile line options used to generate build system files >>> are computed during CMake configuration/generation step. >>> So I don't think what you ask is possible. >>> >>> -- >>> Eric >>> >> > > -- > 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: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Is there a way to delay "find_package" until link-time when the package is actually needed?
Le jeu. 14 févr. 2019 à 18:57, Timothy Wrona a écrit : > The problem is it is very likely that there are some circular dependencies > in the build tree -- which is why it was broken up to generation of all, > then build all, then link all in the first place. > Yes, wrong solution to a real design issue :-) > > With circular dependencies there's no real way to sort these dependencies > out without just running generation twice, but the first run will get a > bunch of errors for missing packages. > I understand the situation, I did face that too in the past. If there is not too much circular deps you may either break them by writing (by hand) a bunch of imported target or you can merge in the same CMake project the sub-projects belonging to the same cycle. Feasibility depends on the amount of projects (and cycle) you have. > > On Thu, Feb 14, 2019 at 12:38 PM Eric Noulard > wrote: > >> >> >> Le jeu. 14 févr. 2019 à 18:22, Timothy Wrona a >> écrit : >> >>> I have a collection of interdependent CMake projects (lots of legacy >>> code) that I want to convert to using CMake targets for linking. The code >>> is built in such a way that all projects run cmake generation, then all >>> projects build, then all projects link. >>> >>> I would like to export a CMake target from one of the projects and link >>> to it in another, but the issue is the project I am exporting from runs its >>> cmake generation AFTER the project I am linking the target in. This causes >>> "find_package" to fail because the target has not been exported yet, but >>> realistically the exported target is not needed until link-time. >>> >> >> This heavily depends on the target. Modern CMake target convey compile >> time information as well like compile flags, include directory etc... >> >> Can't you re-order the cmake generation order of your projects? >> If you [ever] have the graph dependency of your projects you may >> topologically sort them in order to avoid this issue and superbuild them in >> appropriate order. >> >> >>> Is there a way to delay "find_package" to not look for the package until >>> link-time? >>> >> >> I don't think so. >> >> >>> At link-time the package will have been exported already and if >>> "find_package" was not called until then, it would be found successfully >>> and the target could be pulled in and linked to. >>> >> >> But the build compile line options used to generate build system files >> are computed during CMake configuration/generation step. >> So I don't think what you ask is possible. >> >> -- >> Eric >> > -- 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: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Redundant linking when modifying shared libraries
> I wonder why this isn't the default behavior By default CMake wants to get a correct build 100% of the time. There is nothing to stop people from having functions defined in a .cxx file with no corresponding header, and using manual forward deceleration is used in a consuming library/executable. By setting `LINK_DEPENDS_NO_SHARED` to `True` you will convert what was a link time error ( renaming the function in the .cxx ) to a run time error. On Thu, Feb 14, 2019 at 12:11 PM Itay Chamiel wrote: > > On Thu, Feb 14, 2019 at 12:39 PM Craig Scott wrote: > > I think you might be looking for the LINK_DEPENDS_NO_SHARED target property > > (or more likely its associated CMAKE_LINK_DEPENDS_NO_SHARED variable). > > After my previous response I experimented a little more, and I got it > to work. My mistake was that I needed to add the configuration line to > the executable target, not the lib. So in my example, add the > following line to the Demo/CMakeLists.txt file: > > set_target_properties(helloDemo PROPERTIES LINK_DEPENDS_NO_SHARED true) > > ..and it works like a charm. I wonder why this isn't the default > behavior; can you think of any scenario where this would produce > invalid results? > > Thanks for your help! > > itay > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Is there a way to delay "find_package" until link-time when the package is actually needed?
The problem is it is very likely that there are some circular dependencies in the build tree -- which is why it was broken up to generation of all, then build all, then link all in the first place. With circular dependencies there's no real way to sort these dependencies out without just running generation twice, but the first run will get a bunch of errors for missing packages. On Thu, Feb 14, 2019 at 12:38 PM Eric Noulard wrote: > > > Le jeu. 14 févr. 2019 à 18:22, Timothy Wrona a > écrit : > >> I have a collection of interdependent CMake projects (lots of legacy >> code) that I want to convert to using CMake targets for linking. The code >> is built in such a way that all projects run cmake generation, then all >> projects build, then all projects link. >> >> I would like to export a CMake target from one of the projects and link >> to it in another, but the issue is the project I am exporting from runs its >> cmake generation AFTER the project I am linking the target in. This causes >> "find_package" to fail because the target has not been exported yet, but >> realistically the exported target is not needed until link-time. >> > > This heavily depends on the target. Modern CMake target convey compile > time information as well like compile flags, include directory etc... > > Can't you re-order the cmake generation order of your projects? > If you [ever] have the graph dependency of your projects you may > topologically sort them in order to avoid this issue and superbuild them in > appropriate order. > > >> Is there a way to delay "find_package" to not look for the package until >> link-time? >> > > I don't think so. > > >> At link-time the package will have been exported already and if >> "find_package" was not called until then, it would be found successfully >> and the target could be pulled in and linked to. >> > > But the build compile line options used to generate build system files are > computed during CMake configuration/generation step. > So I don't think what you ask is possible. > > -- > 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: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Is there a way to delay "find_package" until link-time when the package is actually needed?
Le jeu. 14 févr. 2019 à 18:22, Timothy Wrona a écrit : > I have a collection of interdependent CMake projects (lots of legacy code) > that I want to convert to using CMake targets for linking. The code is > built in such a way that all projects run cmake generation, then all > projects build, then all projects link. > > I would like to export a CMake target from one of the projects and link to > it in another, but the issue is the project I am exporting from runs its > cmake generation AFTER the project I am linking the target in. This causes > "find_package" to fail because the target has not been exported yet, but > realistically the exported target is not needed until link-time. > This heavily depends on the target. Modern CMake target convey compile time information as well like compile flags, include directory etc... Can't you re-order the cmake generation order of your projects? If you [ever] have the graph dependency of your projects you may topologically sort them in order to avoid this issue and superbuild them in appropriate order. > Is there a way to delay "find_package" to not look for the package until > link-time? > I don't think so. > At link-time the package will have been exported already and if > "find_package" was not called until then, it would be found successfully > and the target could be pulled in and linked to. > But the build compile line options used to generate build system files are computed during CMake configuration/generation step. So I don't think what you ask is possible. -- 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: https://cmake.org/mailman/listinfo/cmake
[CMake] Is there a way to delay "find_package" until link-time when the package is actually needed?
I have a collection of interdependent CMake projects (lots of legacy code) that I want to convert to using CMake targets for linking. The code is built in such a way that all projects run cmake generation, then all projects build, then all projects link. I would like to export a CMake target from one of the projects and link to it in another, but the issue is the project I am exporting from runs its cmake generation AFTER the project I am linking the target in. This causes "find_package" to fail because the target has not been exported yet, but realistically the exported target is not needed until link-time. Is there a way to delay "find_package" to not look for the package until link-time? At link-time the package will have been exported already and if "find_package" was not called until then, it would be found successfully and the target could be pulled in and linked to. Thanks, Tim -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Redundant linking when modifying shared libraries
On Thu, Feb 14, 2019 at 12:39 PM Craig Scott wrote: > I think you might be looking for the LINK_DEPENDS_NO_SHARED target property > (or more likely its associated CMAKE_LINK_DEPENDS_NO_SHARED variable). After my previous response I experimented a little more, and I got it to work. My mistake was that I needed to add the configuration line to the executable target, not the lib. So in my example, add the following line to the Demo/CMakeLists.txt file: set_target_properties(helloDemo PROPERTIES LINK_DEPENDS_NO_SHARED true) ..and it works like a charm. I wonder why this isn't the default behavior; can you think of any scenario where this would produce invalid results? Thanks for your help! itay -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
[Cmake-commits] CMake branch, master, updated. v3.14.0-rc1-109-g8c4de81
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".
The branch, master has been updated
via 8c4de819449bbb1710b1cc2440357757e5cb757c (commit)
via a40864ae53ad22c369596699cc1bb791f65dc360 (commit)
via 724359489e03c1c890bea4bc6ba71ca353b048b9 (commit)
via 6ed4ae4bad3bf3e226e0c8009f9b4057707cfc21 (commit)
via fedbd16f352a8202d30332228ca586a69b513c89 (commit)
from e3353a0175fb27bc2967c3df78b8be1c0615b21d (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8c4de819449bbb1710b1cc2440357757e5cb757c
commit 8c4de819449bbb1710b1cc2440357757e5cb757c
Merge: e3353a0 a40864a
Author: Brad King
AuthorDate: Thu Feb 14 16:01:34 2019 +
Commit: Kitware Robot
CommitDate: Thu Feb 14 11:01:42 2019 -0500
Merge topic 'autogen_refactor_rerun_tests'
a40864ae53 Autogen: Refactor RerunRccDepends test with fixed timestamp
comparison
724359489e Autogen: Refactor RerunRccConfigChange test
6ed4ae4bad Autogen: Refactor RerunMocBasic test with fixed timestamp
comparison
fedbd16f35 Autogen: Refactor RerunMocPlugin test with fixed timestamp
comparison
Acked-by: Kitware Robot
Merge-request: !2959
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a40864ae53ad22c369596699cc1bb791f65dc360
commit a40864ae53ad22c369596699cc1bb791f65dc360
Author: Sebastian Holtermann
AuthorDate: Wed Feb 13 21:08:49 2019 +0100
Commit: Sebastian Holtermann
CommitDate: Wed Feb 13 23:01:46 2019 +0100
Autogen: Refactor RerunRccDepends test with fixed timestamp comparison
This refactors and simplifies the QtAutogen.RerunRccDepends test.
Repetitive task are packed into macros.
By using version strings to store file timestamps, timestamp comparison
becomes more reliable. Test status and error messages are improved.
diff --git a/Tests/QtAutogen/RerunRccDepends/CMakeLists.txt
b/Tests/QtAutogen/RerunRccDepends/CMakeLists.txt
index 80c5cf0..1301550 100644
--- a/Tests/QtAutogen/RerunRccDepends/CMakeLists.txt
+++ b/Tests/QtAutogen/RerunRccDepends/CMakeLists.txt
@@ -3,19 +3,63 @@ project(RerunRccDepends)
include("../AutogenCoreTest.cmake")
# Tests rcc rebuilding when a resource file changes
+# When a .qrc or a file listed in a .qrc file changes,
+# the target must be rebuilt
# Dummy executable to generate a clean target
add_executable(dummy dummy.cpp)
-# When a .qrc or a file listed in a .qrc file changes,
-# the target must be rebuilt
-set(timeformat "%Y%j%H%M%S")
+# Utility variables
+set(timeformat "%Y.%j.%H.%M%S")
set(rccDepSD "${CMAKE_CURRENT_SOURCE_DIR}/RccDepends")
set(rccDepBD "${CMAKE_CURRENT_BINARY_DIR}/RccDepends")
-# Initial build
+# Utility macros
+macro(sleep)
+ message(STATUS "Sleeping for a few seconds.")
+ execute_process(COMMAND "${CMAKE_COMMAND}" -E sleep 1)
+endmacro()
+
+macro(acquire_timestamps When)
+ file(TIMESTAMP "${rccDepBinPlain}" rdPlain${When} "${timeformat}")
+ file(TIMESTAMP "${rccDepBinGenerated}" rdGenerated${When} "${timeformat}")
+endmacro()
+
+macro(rebuild buildName)
+ message(STATUS "Starting build ${buildName} of rccDepends.")
+ execute_process(
+COMMAND "${CMAKE_COMMAND}" --build .
+WORKING_DIRECTORY "${rccDepBD}"
+RESULT_VARIABLE result)
+ if (result)
+message(FATAL_ERROR "Build ${buildName} of rccDepends failed.")
+ else()
+message(STATUS "Build ${buildName} of rccDepends finished.")
+ endif()
+endmacro()
+
+macro(require_change type)
+ if (rd${type}After VERSION_GREATER rd${type}Before)
+message(STATUS "As expected the ${type} .qrc file ${rccDepBin${type}}
changed.")
+ else()
+message(SEND_ERROR "Unexpectedly the ${type} .qrc file ${rccDepBin${type}}
did not change!\nTimestamp pre: ${rd${type}Before}\nTimestamp aft:
${rd${type}After}\n")
+ endif()
+endmacro()
+
+macro(require_change_not type)
+ if (rd${type}After VERSION_GREATER rd${type}Before)
+message(SEND_ERROR "Unexpectedly the ${type} .qrc file ${rccDepBin${type}}
changed!\nTimestamp pre: ${rd${type}Before}\nTimestamp aft:
${rd${type}After}\n")
+ else()
+message(STATUS "As expected the ${type} .qrc file ${rccDepBin${type}} did
not change.")
+ endif()
+endmacro()
+
+
+# Initial configuration
configure_file(${rccDepSD}/resPlainA.qrc.in ${rccDepBD}/resPlain.qrc COPYONLY)
configure_file(${rccDepSD}/resGenA.qrc.in ${rccDepBD}/resGen.qrc.in COPYONLY)
+
+# Initial build
try_compile(RCC_DEPENDS
"${rccDepBD}"
"${rccDepSD}"
@@ -26,113 +70,84 @@ try_compile(RCC_DEPENDS
OUTPUT_VARIABLE output
)
if (NOT RCC_DEPENDS)
- message(SEND_ERROR "Initial build of rccDepends failed. Output: ${output}")
+ message(FATAL_ERROR
[cmake-developers] cuda_compile_ptx re-runs CMake at build time
Hi,
I'm having an issue with CUDA (sadly the old-style FindCUDA, not the new
native support of CUDA).
The following CMake file reproduces the issue easily on Windows with any
Visual Studio Generator (14 2015 Win64 being the one I use).
Adding the file generated by cuda_compile_ptx to any target (even a custom
one) causes CMake to be re-run at compile time.
Which is very annoying, but causes build errors on multi-threaded builds
(permission denied on the vcxproj generated by this CMakeLists.). Of
course, such issues cannot be reproduced with this simple CMakeLists file.
Am I misusing the cuda_compile_ptx method ?
Is there a way to prevent such CMake runs during compile time to occur ?
Thanks.
project(testCuda)
cmake_minimum_required(VERSION 3.10.2)
find_package(CUDA 9.2 REQUIRED)
CUDA_COMPILE_PTX(OBJECT_FILES Arithmetic.cu)
add_library(stuff SHARED SoArithmetic.cxx ${OBJECT_FILES})
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers
Re: [CMake] Multiple occurrences of a library on linux (ldd)
Thanks, Thompson, I will look into BUILD_RPATH and possibly INSTALL_RPATH.
I just learned about `export LD_DEBUG=files` to debug linking issues
on linux. It provides more detail on the ldd output, as below:
18843: file=libc10.so [0]; needed by
/home/dev/miniconda3/datareaders_py37/build/stage/datareader/lib/libdatareader.so
[0]
(no linking information)
18843: file=libdatareader.so [0]; needed by
subprojects/Build/datareaders_core_test/standalone_gtests [0]
18843: file=libdatareader.so [0]; generating link map
(linking information)
(...)
18843: file=libc10.so [0]; needed by
/home/dev/miniconda3/datareaders_py37/build/subprojects/Source/pytorch_external/torch/lib/libcaffe2.so
[0]
18843: file=libc10.so [0]; generating link map
(linking information)
18843: file=libcaffe2.so [0]; needed by
subprojects/Build/datareaders_core_test/standalone_gtests [0]
18843: file=libcaffe2.so [0]; generating link map
(linking information)
Now I can see that the missing libc10.so is needed by
`libdatareader.so`, which was linked against `standalone_gtests`.
However, RUNPATH for both `libdatareader.so` and `standalone_gtests`
seems to be correct and point to the same torch/lib folder that has
libc10.so:
libdatareader.so:
RUNPATH=/home/dev/miniconda3/datareaders_py37/build/stage/boost/lib:/home/dev/miniconda3/datareaders_py37/build/subprojects/Source/pytorch_external/torch/lib:
standalone_gtests:
RUNPATH=/home/dev/miniconda3/datareaders_py37/build/stage/boost/lib:/home/dev/miniconda3/datareaders_py37/build/subprojects/Source/pytorch_external/torch/lib:/home/dev/miniconda3/datareaders_py37/build/stage/datareader/lib
So, libdatareader.so links to libcaffe2.so which links to libc10.so
successfully; standalone_gtests links to libcaffe2.so which links to
libc10.so successully too; however, when standalone_gtests links to
libdatareader.so, there is a transitive linking issue with
libdatareader.so dependency on libc10.so, like the diagram below:
libdatareader.so ---> libcaffe2.so ---> libc10.so (ok)
standalone_gtests 0 ---> libcaffe2.so ---> libc10.so (ok)
|
---> libdatareader.so ---> libc10.so (not found)
Thanks again,
Thiago
On Thu, Feb 14, 2019 at 6:13 AM Thompson, KT wrote:
>
> Thiago,
>
>
>
> I haven’t see the double entry pattern that you mention below. However, you
> might want to tell CMake to embed a BUILD_RPATH in your libraries. This
> should get around the issue of manually setting LD_LIBRARY_PATH.
>
>
>
> https://cmake.org/cmake/help/latest/prop_tgt/BUILD_RPATH.html?highlight=rpath
>
>
>
> -kt
>
>
>
> From: CMake On Behalf Of Thiago Crepaldi
> Sent: Thursday, February 14, 2019 12:43 AM
> To: cmake@cmake.org
> Subject: [CMake] Multiple occurrences of a library on linux (ldd)
>
>
>
> Hello all,
>
>
>
> After reading CMake Cookbook I have written my first "complex" CMake build
> script based on the superbuild pattern. I am excited to heave a better
> understanding on CMake, but I definitely will learn much more from experience
> and your kind help.
>
> In summary, the standalone google test application `standalone_gtests`
> publicly links to `libdatareader.so` and to pytorch libraries
> (`libc10.so`,`libcafee2.so`, `libtorch.so`).
>
> `libdatareader.so` also publicly links to pytorch libraries (I have a
> theoretical question on why `standalone_gtests` had to link to pytorch
> libraries if `libdatareader.so` already did, but that can wait).
>
>
>
> Compilation finishes successfully, but when I try to run `standalone_gtests`,
> it aborts because it cant find `libc10.so`.
>
> After executing `ldd standalone_gtests`, the weird result was that there were
> two entries for `libc10.so`.
>
> The first one maps to "not found" while the second had the correct path to
> the library. `libcaffe2.so`, which is also a pytorch library, has a single
> occurrence with full path.
>
> If I add the (...)/pytorch_external/(...) (see ldd output below) path to
> LD_LIBRARY_PATH, then everything works, but I would like to avoid this, if
> possible.
>
>
>
> `ldd ./subprojects/Build/datareaders_core_test/standalone_gtests
>
> libdatareader.so =>
> /home/dev/miniconda3/datareaders_py37/build/stage/datareader/lib/libdatareader.so
>
> libcaffe2.so =>
> /home/dev/miniconda3/datareaders_py37/build/subprojects/Source/pytorch_external/torch/lib/libcaffe2.so
>
> libc10.so => not found
>
> libc10.so =>
> /home/dev/miniconda3/datareaders_py37/build/subprojects/Source/pytorch_external/torch/lib/libc10.so
>
> (...)`
>
>
>
> Have anyone seen multiple entries for the same library on ldd before? Why is
> that? Is it because `standalone_gtests` links to libc10.so and to
> `libdatareader.so`, which in turn also links to `libc10.so`?
>
> Both CMakeLists.txt (libdatareader and standalone_gtests) succeeds at
> find_package(Torch REQUIRED QUIET) commands (${TORCH_LIBRARY} returns the
> correct path).
>
>
>
>
>
> I run the same
[Cmake-commits] CMake branch, release, updated. v3.14.0-rc1-29-g2f51f28
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, release has been updated via 2f51f281a8c9684c25cf97499a4382e1b5ae68b9 (commit) via d80ecba5c27ec249dc85c3a3559db822ef320d05 (commit) via 72057d9c1582f4b6dec66cd0675860c4c335636e (commit) via 7ae329e2ed84f62165cb11794ad85c6c43dbd7dc (commit) via 9f351b93ab7684940ad2da14fd6800f11f09355f (commit) via 76a5ac210050e0c1ccdce8ce89a0c77579e30187 (commit) via 30783addc12d82081575f5a7577d7b4953cbd55c (commit) via 6fc33829443ea3ef2dc8cc71c0a98b635bec6179 (commit) via 2ad14ef4ea57c19f6cb4ed365e99a30be81eefe7 (commit) via 557b2d6e65038640d5016413e612e48691cff0d8 (commit) via 017598a4443c19185dc245f3f0fcfceff9b98463 (commit) from 1c4570e22eb7fcf312426e4e1fb0db0c2a3d5d33 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - --- Summary of changes: Modules/Compiler/Flang-Fortran.cmake | 3 +++ Modules/Compiler/GNU-Fortran.cmake | 3 +++ Modules/Compiler/Intel-Fortran.cmake | 3 +++ Modules/Compiler/PGI-Fortran.cmake | 3 +++ Modules/Compiler/XL-Fortran.cmake| 3 +++ Modules/Platform/Darwin.cmake| 2 +- Modules/Platform/UnixPaths.cmake | 5 - Source/LexerParser/cmListFileLexer.c | 2 +- Source/LexerParser/cmListFileLexer.in.l | 2 +- Source/cmAlgorithms.h| 8 Source/cmDependsFortran.cxx | 11 ++- Source/cmDependsFortran.h| 4 Source/cmFortranParser.h | 16 +++- Source/cmFortranParserImpl.cxx | 29 + Source/cmGlobalNinjaGenerator.cxx| 12 +++- Source/cmLocalGenerator.cxx | 28 +--- Source/cmLocalUnixMakefileGenerator3.cxx | 11 +++ Source/cmNinjaTargetGenerator.cxx| 4 18 files changed, 123 insertions(+), 26 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org https://cmake.org/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v3.14.0-rc1-104-ge3353a0
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, master has been updated via e3353a0175fb27bc2967c3df78b8be1c0615b21d (commit) via 2f51f281a8c9684c25cf97499a4382e1b5ae68b9 (commit) via 9f351b93ab7684940ad2da14fd6800f11f09355f (commit) via 30783addc12d82081575f5a7577d7b4953cbd55c (commit) from 0069825f50c83b8144374150dd682d48c84f6874 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e3353a0175fb27bc2967c3df78b8be1c0615b21d commit e3353a0175fb27bc2967c3df78b8be1c0615b21d Merge: 0069825 2f51f28 Author: Brad King AuthorDate: Thu Feb 14 10:35:22 2019 -0500 Commit: Brad King CommitDate: Thu Feb 14 10:35:22 2019 -0500 Merge branch 'release-3.14' --- Summary of changes: hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org https://cmake.org/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v3.14.0-rc1-100-g0069825
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".
The branch, master has been updated
via 0069825f50c83b8144374150dd682d48c84f6874 (commit)
via d80ecba5c27ec249dc85c3a3559db822ef320d05 (commit)
via 72057d9c1582f4b6dec66cd0675860c4c335636e (commit)
via 7ae329e2ed84f62165cb11794ad85c6c43dbd7dc (commit)
from 50ba2f019baa3e5487a975cb72059f1fc178f9d0 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0069825f50c83b8144374150dd682d48c84f6874
commit 0069825f50c83b8144374150dd682d48c84f6874
Merge: 50ba2f0 d80ecba
Author: Brad King
AuthorDate: Thu Feb 14 15:25:08 2019 +
Commit: Kitware Robot
CommitDate: Thu Feb 14 10:25:15 2019 -0500
Merge topic 'fortran-submodule-names'
d80ecba5c2 Fortran: Fix submodule file names across compilers
72057d9c15 Fortran: Thread compiler id through to internal Fortran parser
7ae329e2ed Fortran: Factor out .mod and .smod file name construction
Acked-by: Kitware Robot
Acked-by: Michael Hirsch, Ph.D.
Merge-request: !2958
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d80ecba5c27ec249dc85c3a3559db822ef320d05
commit d80ecba5c27ec249dc85c3a3559db822ef320d05
Author: Brad King
AuthorDate: Wed Feb 13 14:08:34 2019 -0500
Commit: Brad King
CommitDate: Thu Feb 14 10:23:02 2019 -0500
Fortran: Fix submodule file names across compilers
The naming convention for submodule files varies across compilers. Add
a table to the compiler information modules and thread the information
through to the Fortran module dependency parser. Fill out the table for
compiler ids known to support Fortran submodules.
Fixes: #18746
diff --git a/Modules/Compiler/Flang-Fortran.cmake
b/Modules/Compiler/Flang-Fortran.cmake
index d522739..f0e61d8 100644
--- a/Modules/Compiler/Flang-Fortran.cmake
+++ b/Modules/Compiler/Flang-Fortran.cmake
@@ -1,6 +1,9 @@
include(Compiler/Clang)
__compiler_clang(Fortran)
+set(CMAKE_Fortran_SUBMODULE_SEP "-")
+set(CMAKE_Fortran_SUBMODULE_EXT ".mod")
+
set(CMAKE_Fortran_PREPROCESS_SOURCE
" -cpp-E >
")
diff --git a/Modules/Compiler/GNU-Fortran.cmake
b/Modules/Compiler/GNU-Fortran.cmake
index c333d50..6413769 100644
--- a/Modules/Compiler/GNU-Fortran.cmake
+++ b/Modules/Compiler/GNU-Fortran.cmake
@@ -1,6 +1,9 @@
include(Compiler/GNU)
__compiler_gnu(Fortran)
+set(CMAKE_Fortran_SUBMODULE_SEP "@")
+set(CMAKE_Fortran_SUBMODULE_EXT ".smod")
+
set(CMAKE_Fortran_PREPROCESS_SOURCE
" -cpp-E -o
")
diff --git a/Modules/Compiler/Intel-Fortran.cmake
b/Modules/Compiler/Intel-Fortran.cmake
index a132055..5275ddf 100644
--- a/Modules/Compiler/Intel-Fortran.cmake
+++ b/Modules/Compiler/Intel-Fortran.cmake
@@ -1,6 +1,9 @@
include(Compiler/Intel)
__compiler_intel(Fortran)
+set(CMAKE_Fortran_SUBMODULE_SEP "@")
+set(CMAKE_Fortran_SUBMODULE_EXT ".smod")
+
set(CMAKE_Fortran_MODDIR_FLAG "-module ")
set(CMAKE_Fortran_FORMAT_FIXED_FLAG "-fixed")
set(CMAKE_Fortran_FORMAT_FREE_FLAG "-free")
diff --git a/Modules/Compiler/PGI-Fortran.cmake
b/Modules/Compiler/PGI-Fortran.cmake
index a183c33..3daf798 100644
--- a/Modules/Compiler/PGI-Fortran.cmake
+++ b/Modules/Compiler/PGI-Fortran.cmake
@@ -1,6 +1,9 @@
include(Compiler/PGI)
__compiler_pgi(Fortran)
+set(CMAKE_Fortran_SUBMODULE_SEP "-")
+set(CMAKE_Fortran_SUBMODULE_EXT ".mod")
+
set(CMAKE_Fortran_PREPROCESS_SOURCE
" -Mpreprocess-E
> ")
diff --git a/Modules/Compiler/XL-Fortran.cmake
b/Modules/Compiler/XL-Fortran.cmake
index 6bab6f6..c4fb097 100644
--- a/Modules/Compiler/XL-Fortran.cmake
+++ b/Modules/Compiler/XL-Fortran.cmake
@@ -1,6 +1,9 @@
include(Compiler/XL)
__compiler_xl(Fortran)
+set(CMAKE_Fortran_SUBMODULE_SEP "_")
+set(CMAKE_Fortran_SUBMODULE_EXT ".smod")
+
set(CMAKE_Fortran_FORMAT_FIXED_FLAG "-qfixed") # [=]
set(CMAKE_Fortran_FORMAT_FREE_FLAG "-qfree") # [=f90|ibm]
diff --git a/Source/cmDependsFortran.cxx b/Source/cmDependsFortran.cxx
index fe69d14..3f036a9 100644
--- a/Source/cmDependsFortran.cxx
+++ b/Source/cmDependsFortran.cxx
@@ -96,6 +96,8 @@ cmDependsFortran::cmDependsFortran(cmLocalGenerator* lg)
}
this->CompilerId = mf->GetSafeDefinition("CMAKE_Fortran_COMPILER_ID");
+ this->SModSep = mf->GetSafeDefinition("CMAKE_Fortran_SUBMODULE_SEP");
+ this->SModExt = mf->GetSafeDefinition("CMAKE_Fortran_SUBMODULE_EXT");
}
cmDependsFortran::~cmDependsFortran()
@@ -120,6 +122,8 @@ bool cmDependsFortran::WriteDependencies(const
std::set& sources,
cmFortranCompiler fc;
fc.Id = this->CompilerId;
+ fc.SModSep = this->SModSep;
+ fc.SModExt = this->SModExt;
bool okay = true;
for
[Cmake-commits] CMake branch, master, updated. v3.14.0-rc1-96-g50ba2f0
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".
The branch, master has been updated
via 50ba2f019baa3e5487a975cb72059f1fc178f9d0 (commit)
via fd74eba1402d66a4d6a1af3442cf219d02f7cbc8 (commit)
via 76a5ac210050e0c1ccdce8ce89a0c77579e30187 (commit)
via 6fc33829443ea3ef2dc8cc71c0a98b635bec6179 (commit)
via 2ad14ef4ea57c19f6cb4ed365e99a30be81eefe7 (commit)
via 557b2d6e65038640d5016413e612e48691cff0d8 (commit)
via 017598a4443c19185dc245f3f0fcfceff9b98463 (commit)
from 49a53cac87fe3a303a2794ccdd7c1b5cecd2d016 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=50ba2f019baa3e5487a975cb72059f1fc178f9d0
commit 50ba2f019baa3e5487a975cb72059f1fc178f9d0
Merge: fd74eba 6fc3382
Author: Brad King
AuthorDate: Thu Feb 14 15:14:11 2019 +
Commit: Kitware Robot
CommitDate: Thu Feb 14 10:14:47 2019 -0500
Merge topic 'fix-legacy-implicit-includes'
6fc3382944 Update logic for sysroot in detected implicit include directories
2ad14ef4ea cmAlgorithms: Add cmHasPrefix to match existing cmHasSuffix
557b2d6e65 Fix regression in -I/usr/include exclusion logic
017598a444 macOS: Fix addition of /usr/include to default implicit
include dirs
Acked-by: Kitware Robot
Merge-request: !2957
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fd74eba1402d66a4d6a1af3442cf219d02f7cbc8
commit fd74eba1402d66a4d6a1af3442cf219d02f7cbc8
Merge: 49a53ca 76a5ac2
Author: Brad King
AuthorDate: Thu Feb 14 15:14:02 2019 +
Commit: Kitware Robot
CommitDate: Thu Feb 14 10:14:08 2019 -0500
Merge topic 'fix-pointer-truncation'
76a5ac2100 cmListFileLexer: Add missing include to avoid possible pointer
truncation
Acked-by: Kitware Robot
Merge-request: !2956
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=76a5ac210050e0c1ccdce8ce89a0c77579e30187
commit 76a5ac210050e0c1ccdce8ce89a0c77579e30187
Author: Zsolt Parragi
AuthorDate: Tue Feb 12 21:01:18 2019 +0100
Commit: Brad King
CommitDate: Wed Feb 13 10:22:59 2019 -0500
cmListFileLexer: Add missing include to avoid possible pointer truncation
The `cmsys/Enconding.h` include had a typo in its surrounding ifdef,
possibly causing a missing function declaration (`cmsysEncoding_DupToWide`).
As this is C code, this resulted in the code compiling, but with a truncated
return value, possibly causing crashes.
diff --git a/Source/LexerParser/cmListFileLexer.c
b/Source/LexerParser/cmListFileLexer.c
index c726415..15dcda0 100644
--- a/Source/LexerParser/cmListFileLexer.c
+++ b/Source/LexerParser/cmListFileLexer.c
@@ -766,7 +766,7 @@ Modify cmListFileLexer.c:
/* IWYU pragma: no_forward_declare yyguts_t */
-#ifdef WIN32
+#ifdef _WIN32
#include "cmsys/Encoding.h"
#endif
diff --git a/Source/LexerParser/cmListFileLexer.in.l
b/Source/LexerParser/cmListFileLexer.in.l
index 6a6fb5f..fdf14d2 100644
--- a/Source/LexerParser/cmListFileLexer.in.l
+++ b/Source/LexerParser/cmListFileLexer.in.l
@@ -18,7 +18,7 @@ Modify cmListFileLexer.c:
/* IWYU pragma: no_forward_declare yyguts_t */
-#ifdef WIN32
+#ifdef _WIN32
#include "cmsys/Encoding.h"
#endif
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6fc33829443ea3ef2dc8cc71c0a98b635bec6179
commit 6fc33829443ea3ef2dc8cc71c0a98b635bec6179
Author: Brad King
AuthorDate: Wed Feb 13 09:27:24 2019 -0500
Commit: Brad King
CommitDate: Wed Feb 13 10:03:56 2019 -0500
Update logic for sysroot in detected implicit include directories
Since commit 5990ecb741 (Compute implicit include directories from
compiler output, 2018-12-07, v3.14.0-rc1~108^2) the values of the
`CMAKE__IMPLICIT_INCLUDE_DIRECTORIES` variables are computed from
a real compiler invocation. In this case the paths under the sysroot
should already have the sysroot prefix so we should no longer have to
add the sysroot prefix. However, it is also possible for project code
to add its own paths to `CMAKE__IMPLICIT_INCLUDE_DIRECTORIES`
without the sysroot prefix and expect the historical addition of the
sysroot prefix to be preserved.
Try to account for both cases by conditionally adding the sysroot prefix
on implicit include directories that do not already have it.
diff --git a/Source/cmLocalGenerator.cxx b/Source/cmLocalGenerator.cxx
index b1115ea..8090e00 100644
--- a/Source/cmLocalGenerator.cxx
+++ b/Source/cmLocalGenerator.cxx
@@ -935,6 +935,7 @@ std::vector>
cmLocalGenerator::GetIncludeDirectoriesImplicit(
} else {
rootPath = this->Makefile->GetSafeDefinition("CMAKE_SYSROOT");
}
+
[Cmake-commits] CMake branch, master, updated. v3.14.0-rc1-89-g49a53ca
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".
The branch, master has been updated
via 49a53cac87fe3a303a2794ccdd7c1b5cecd2d016 (commit)
via ec13bd523006151b4e0d2b9afc19562e5f05de38 (commit)
via ded4bc136e5b120b2d047dc9b8eb6f7446043d08 (commit)
via f3999a21c85e6caf19feef7c90afce3969d9102a (commit)
from 5b3683ec8a23d8cecb27f3cd2e3a649ae6ad5999 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=49a53cac87fe3a303a2794ccdd7c1b5cecd2d016
commit 49a53cac87fe3a303a2794ccdd7c1b5cecd2d016
Merge: 5b3683e ec13bd5
Author: Brad King
AuthorDate: Thu Feb 14 15:11:40 2019 +
Commit: Kitware Robot
CommitDate: Thu Feb 14 10:11:54 2019 -0500
Merge topic 'update-kwsys'
ec13bd5230 Tests: Disable test that builds KWSys if not also building CMake
ded4bc136e Merge branch 'upstream-KWSys' into update-kwsys
f3999a21c8 KWSys 2019-02-12 (44676809)
Acked-by: Kitware Robot
Merge-request: !2953
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ec13bd523006151b4e0d2b9afc19562e5f05de38
commit ec13bd523006151b4e0d2b9afc19562e5f05de38
Author: Brad King
AuthorDate: Wed Feb 13 08:07:54 2019 -0500
Commit: Brad King
CommitDate: Wed Feb 13 08:10:35 2019 -0500
Tests: Disable test that builds KWSys if not also building CMake
If `CMake_TEST_EXTERNAL_CMAKE` is enabled then the compiler with which
we are driving tests may not be able to compile CMake, so do not try
to compile KWSys with it either.
diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt
index 40e53a2..3245f3e 100644
--- a/Tests/CMakeLists.txt
+++ b/Tests/CMakeLists.txt
@@ -3272,12 +3272,14 @@ ${CMake_BINARY_DIR}/bin/cmake -DDIR=dev -P
${CMake_SOURCE_DIR}/Utilities/Release
--output-log "${CMake_BINARY_DIR}/Tests/CTestTest/testOutput.log"
)
-configure_file("${CMake_SOURCE_DIR}/Tests/CTestTest2/test.cmake.in"
- "${CMake_BINARY_DIR}/Tests/CTestTest2/test.cmake" @ONLY ESCAPE_QUOTES)
-add_test(CTestTest2 ${CMAKE_CTEST_COMMAND}
- -S "${CMake_BINARY_DIR}/Tests/CTestTest2/test.cmake" -V
- --output-log "${CMake_BINARY_DIR}/Tests/CTestTest2/testOutput.log"
- )
+if(NOT CMake_TEST_EXTERNAL_CMAKE)
+ configure_file("${CMake_SOURCE_DIR}/Tests/CTestTest2/test.cmake.in"
+"${CMake_BINARY_DIR}/Tests/CTestTest2/test.cmake" @ONLY ESCAPE_QUOTES)
+ add_test(CTestTest2 ${CMAKE_CTEST_COMMAND}
+-S "${CMake_BINARY_DIR}/Tests/CTestTest2/test.cmake" -V
+--output-log "${CMake_BINARY_DIR}/Tests/CTestTest2/testOutput.log"
+)
+endif()
if("${CMAKE_GENERATOR}" MATCHES "Makefiles" OR "${CMAKE_GENERATOR}"
MATCHES "Ninja")
configure_file("${CMake_SOURCE_DIR}/Tests/CTestTestLaunchers/test.cmake.in"
@@ -3309,11 +3311,13 @@ ${CMake_BINARY_DIR}/bin/cmake -DDIR=dev -P
${CMake_SOURCE_DIR}/Utilities/Release
PROPERTIES TIMEOUT ${CMAKE_LONG_TEST_TIMEOUT})
endif ()
-get_test_property(CTestTest2 TIMEOUT PREVIOUS_TIMEOUT)
-if ("${PREVIOUS_TIMEOUT}" MATCHES NOTFOUND)
- set_tests_properties ( CTestTest2
-PROPERTIES TIMEOUT ${CMAKE_LONG_TEST_TIMEOUT})
-endif ()
+if(NOT CMake_TEST_EXTERNAL_CMAKE)
+ get_test_property(CTestTest2 TIMEOUT PREVIOUS_TIMEOUT)
+ if("${PREVIOUS_TIMEOUT}" MATCHES NOTFOUND)
+set_tests_properties ( CTestTest2
+ PROPERTIES TIMEOUT ${CMAKE_LONG_TEST_TIMEOUT})
+ endif()
+endif()
endif ()
if(CMake_TEST_EXTERNAL_CMAKE)
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ded4bc136e5b120b2d047dc9b8eb6f7446043d08
commit ded4bc136e5b120b2d047dc9b8eb6f7446043d08
Merge: 9d2ab63 f3999a2
Author: Brad King
AuthorDate: Tue Feb 12 08:35:12 2019 -0500
Commit: Brad King
CommitDate: Tue Feb 12 08:35:12 2019 -0500
Merge branch 'upstream-KWSys' into update-kwsys
* upstream-KWSys:
KWSys 2019-02-12 (44676809)
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f3999a21c85e6caf19feef7c90afce3969d9102a
commit f3999a21c85e6caf19feef7c90afce3969d9102a
Author: KWSys Upstream
AuthorDate: Tue Feb 12 08:34:34 2019 -0500
Commit: Brad King
CommitDate: Tue Feb 12 08:35:11 2019 -0500
KWSys 2019-02-12 (44676809)
Code extracted from:
https://gitlab.kitware.com/utils/kwsys.git
at commit 4467680959f82b755462a8530ef5d0dbd928d2d4 (master).
Upstream Shortlog
-
Albert Astals Cid (1):
7d50c26d Delete some default constructors and assignment operators
Artur Ryt (1):
01089e4c Prefer back/data over dereferencing rbegin/begin iterator
diff --git
Re: [CMake] Multiple occurrences of a library on linux (ldd)
Thiago,
I haven’t see the double entry pattern that you mention below. However, you
might want to tell CMake to embed a BUILD_RPATH in your libraries. This should
get around the issue of manually setting LD_LIBRARY_PATH.
https://cmake.org/cmake/help/latest/prop_tgt/BUILD_RPATH.html?highlight=rpath
-kt
From: CMake On Behalf Of Thiago Crepaldi
Sent: Thursday, February 14, 2019 12:43 AM
To: cmake@cmake.org
Subject: [CMake] Multiple occurrences of a library on linux (ldd)
Hello all,
After reading CMake Cookbook I have written my first "complex" CMake build
script based on the superbuild pattern. I am excited to heave a better
understanding on CMake, but I definitely will learn much more from experience
and your kind help.
In summary, the standalone google test application `standalone_gtests` publicly
links to `libdatareader.so` and to pytorch libraries
(`libc10.so`,`libcafee2.so`, `libtorch.so`).
`libdatareader.so` also publicly links to pytorch libraries (I have a
theoretical question on why `standalone_gtests` had to link to pytorch
libraries if `libdatareader.so` already did, but that can wait).
Compilation finishes successfully, but when I try to run `standalone_gtests`,
it aborts because it cant find `libc10.so`.
After executing `ldd standalone_gtests`, the weird result was that there were
two entries for `libc10.so`.
The first one maps to "not found" while the second had the correct path to the
library. `libcaffe2.so`, which is also a pytorch library, has a single
occurrence with full path.
If I add the (...)/pytorch_external/(...) (see ldd output below) path to
LD_LIBRARY_PATH, then everything works, but I would like to avoid this, if
possible.
`ldd ./subprojects/Build/datareaders_core_test/standalone_gtests
libdatareader.so =>
/home/dev/miniconda3/datareaders_py37/build/stage/datareader/lib/libdatareader.so
libcaffe2.so =>
/home/dev/miniconda3/datareaders_py37/build/subprojects/Source/pytorch_external/torch/lib/libcaffe2.so
libc10.so => not found
libc10.so =>
/home/dev/miniconda3/datareaders_py37/build/subprojects/Source/pytorch_external/torch/lib/libc10.so
(...)`
Have anyone seen multiple entries for the same library on ldd before? Why is
that? Is it because `standalone_gtests` links to libc10.so and to
`libdatareader.so`, which in turn also links to `libc10.so`?
Both CMakeLists.txt (libdatareader and standalone_gtests) succeeds at
find_package(Torch REQUIRED QUIET) commands (${TORCH_LIBRARY} returns the
correct path).
I run the same build on my Mac and everything works fine, so that is confined
to linux environment. I have destroyed my conda environment and performed
multiple clean builds in the process and no luck :(
Hoping this was some sort of ldconfig issue, I tried `sudo ldconfig` and `sudo
rm /etc/ld.so.cache`, but that doesn't fix it.
Any ideas?
best regards,
Thiago
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] Properly Documenting a CMake Module
That's what I was looking for! Thanks!!! On Thu, Feb 14, 2019 at 9:04 AM wrote: > > > > Am 14.02.2019 um 14:53 schrieb Timothy Wrona : > > > > How does Sphinx know to go parse that ".cmake" file? Does Sphinx > recognize the „cmake-module" keyword in a special way and know what to do > with it? > > it’s from a Sphinx module that you can find the in the CMake sources > Utilities/Sphinx/cmake.py. Or you can install this file using pip: > > > pip install sphinxcontrib-moderncmakedomain > > When configuring Sphinx, you have to name the extensions to use in > Sphinx's configuration file (conf.py) and add the name of the extension > (sphinxcontrib.moderncmakedomain) to the extensions array. > > best regards, > > Torsten > -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake-developers
Re: [cmake-developers] Properly Documenting a CMake Module
> Am 14.02.2019 um 14:53 schrieb Timothy Wrona : > > How does Sphinx know to go parse that ".cmake" file? Does Sphinx recognize > the „cmake-module" keyword in a special way and know what to do with it? it’s from a Sphinx module that you can find the in the CMake sources Utilities/Sphinx/cmake.py. Or you can install this file using pip: > pip install sphinxcontrib-moderncmakedomain When configuring Sphinx, you have to name the extensions to use in Sphinx's configuration file (conf.py) and add the name of the extension (sphinxcontrib.moderncmakedomain) to the extensions array. best regards, Torsten signature.asc Description: Message signed with OpenPGP -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake-developers
Re: [cmake-developers] Properly Documenting a CMake Module
Hi Gregor, It looks like there's still a little bit of magic here. All those "Help/.rst" files just have a single line in them that says: .. cmake-module:: ../../Modules/.cmake How does Sphinx know to go parse that ".cmake" file? Does Sphinx recognize the "cmake-module" keyword in a special way and know what to do with it? Thanks, Tim -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake-developers
Re: [CMake] Redundant linking when modifying shared libraries
On 2/14/19 12:38 PM, Craig Scott wrote: I think you might be looking for the LINK_DEPENDS_NO_SHARED target property (or more likely its associated CMAKE_LINK_DEPENDS_NO_SHARED variable). Following with my example, I've added the following line to the file Hello/CMakeLists.txt: set_target_properties(Hello PROPERTIES LINK_DEPENDS_NO_SHARED true) However it has no effect. Touching the file Hello/hello.cpp will still cause the "Linking CXX executable helloDemo" step to be performed. I've also tried adding the same line to the CMakeLists.txt file in the root directory, it also had no effect. Thank you, itay -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Redundant linking when modifying shared libraries
On Thu, Feb 14, 2019 at 9:24 PM Itay Chamiel wrote:
> Hi,
>
> I've asked this question on Stack Overflow almost a year ago with no
> useful responses (with the same topic if you wish to search for it), so I'm
> trying my luck here.
>
> I work on a large commercial C++ project comprised of a couple dozen
> dynamically linked shared libraries, each of which has many associated unit
> tests. Many libs are also dependent on other libs because a lib for some
> specific functionality will use the code from one of the more common libs.
> And finally of course there are the production executables which depend on
> the libs.
>
> There is no question that a change in the API (a header file) of some core
> common lib should trigger a major recompilation of nearly the entire
> system. But typically there is only a change in some function's
> implementation, and the only file compiled is the modified .cpp file, and
> in theory just the modified lib would need to be linked - thanks to dynamic
> linking there should be no need to relink anything else. But CMake goes
> ahead and does it anyway: after relinking the lib it relinks all the unit
> tests associated with that lib. Then it relinks all the libs in that lib's
> dependency tree and all their unit tests. Finally it relinks the production
> executables. Due to the scale of the project this takes a lot of precious
> time.
>
> I have reproduced this behavior with a simple project based on the example
> at cmake.org/examples (comments removed for brevity and lib type changed
> to shared). My system is Ubuntu 16 on an Intel PC and my CMake version is
> 3.5.1.
>
> Start with an empty directory. Create subdirectories Demo and Hello and
> then create these files:
>
> * CMakeLists.txt
>
> cmake_minimum_required (VERSION 2.8.11)
> project (HELLO)
> add_subdirectory (Hello)
> add_subdirectory (Demo)
>
> * Demo/CMakeLists.txt
>
> add_executable (helloDemo demo.cpp)
> target_link_libraries (helloDemo LINK_PUBLIC Hello)
>
> * Demo/demo.cpp
>
> #include "hello.h"
> int main() { hello(); }
>
> * Hello/CMakeLists.txt
>
> add_library (Hello SHARED hello.cpp)
> target_include_directories (Hello PUBLIC ${CMAKE_CURRENT_SOURCE_DIR})
>
> * Hello/hello.h
>
> void hello();
>
> * Hello/hello.cpp
>
> #include
> void hello() { printf("hello!\n"); }
>
> * now run the commands:
>
> mkdir build
> cd build
> cmake ../
> make
>
> * You may now execute Demo/helloDemo and see hello!.
>
> Now, touch Hello/hello.cpp and make again. You will see that libHello is
> built and linked as expected, but then the helloDemo executable is also
> relinked ("Linking CXX executable helloDemo"). The latter step is
> completely redundant; even if hello.cpp is modified to print a different
> string the relinked executable remains binary identical.
>
> Is there a way to prevent these redundant build actions? This would be a
> huge time saver for us.
>
I think you might be looking for the LINK_DEPENDS_NO_SHARED
target
property (or more likely its associated CMAKE_LINK_DEPENDS_NO_SHARED
variable).
--
Craig Scott
Melbourne, Australia
https://crascit.com
Get the hand-book for every CMake user: Professional CMake: A Practical
Guide
[CMake] Redundant linking when modifying shared libraries
Hi,
I've asked this question on Stack Overflow almost a year ago with no useful
responses (with the same topic if you wish to search for it), so I'm trying
my luck here.
I work on a large commercial C++ project comprised of a couple dozen
dynamically linked shared libraries, each of which has many associated unit
tests. Many libs are also dependent on other libs because a lib for some
specific functionality will use the code from one of the more common libs.
And finally of course there are the production executables which depend on
the libs.
There is no question that a change in the API (a header file) of some core
common lib should trigger a major recompilation of nearly the entire
system. But typically there is only a change in some function's
implementation, and the only file compiled is the modified .cpp file, and
in theory just the modified lib would need to be linked - thanks to dynamic
linking there should be no need to relink anything else. But CMake goes
ahead and does it anyway: after relinking the lib it relinks all the unit
tests associated with that lib. Then it relinks all the libs in that lib's
dependency tree and all their unit tests. Finally it relinks the production
executables. Due to the scale of the project this takes a lot of precious
time.
I have reproduced this behavior with a simple project based on the example
at cmake.org/examples (comments removed for brevity and lib type changed to
shared). My system is Ubuntu 16 on an Intel PC and my CMake version is
3.5.1.
Start with an empty directory. Create subdirectories Demo and Hello and
then create these files:
* CMakeLists.txt
cmake_minimum_required (VERSION 2.8.11)
project (HELLO)
add_subdirectory (Hello)
add_subdirectory (Demo)
* Demo/CMakeLists.txt
add_executable (helloDemo demo.cpp)
target_link_libraries (helloDemo LINK_PUBLIC Hello)
* Demo/demo.cpp
#include "hello.h"
int main() { hello(); }
* Hello/CMakeLists.txt
add_library (Hello SHARED hello.cpp)
target_include_directories (Hello PUBLIC ${CMAKE_CURRENT_SOURCE_DIR})
* Hello/hello.h
void hello();
* Hello/hello.cpp
#include
void hello() { printf("hello!\n"); }
* now run the commands:
mkdir build
cd build
cmake ../
make
* You may now execute Demo/helloDemo and see hello!.
Now, touch Hello/hello.cpp and make again. You will see that libHello is
built and linked as expected, but then the helloDemo executable is also
relinked ("Linking CXX executable helloDemo"). The latter step is
completely redundant; even if hello.cpp is modified to print a different
string the relinked executable remains binary identical.
Is there a way to prevent these redundant build actions? This would be a
huge time saver for us.
Thank you,
itay
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] Properly Documenting a CMake Module
Hello, On 14.02.19 04:39, Timothy Wrona wrote: Okay so I dug a little deeper into this and it definitely looks like sphinx is the correct tool to use, but I still have one problem. I would like sphinx to be able to extract ".rst" formatted comments directly out of my cmake source files to produce the documentation but I can't seem to figure out how. The standard modules that ship with cmake all have this ".rst" section at the top that seems to magically get extracted and turned into online documentation with sphinx, but I just can't figure out how they do it. The standard modules have a shadow hierarchy at Help/module. For example https://gitlab.kitware.com/cmake/cmake/blob/master/Help/module/GNUInstallDirs.rst contains .. cmake-module:: ../../Modules/GNUInstallDirs.cmake There's no magic happening. Thanks, Gregor -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake-developers
