Re: [CMake] CMAKE_*_IMPLICIT_INCLUDE_DIRECTORIES with MinGW
Hi everyone,
any feedback on this?
As a summary, it's about adding the default include paths of GCC to the
variables "CMAKE_*_IMPLICIT_INCLUDE_DIRECTORIES" to avoid CMake modules
or scripts to mess up with them, more specifically with their order.
Cheers,
Olivier
On 2018-11-3 21:41, Olivier Croquette wrote:
Hi,
I got recently build errors when introducing external dependencies in
my project, the reason is that those components re-add standard SYSTEM
include search paths, which changes the search order and causes
#include_next to fail. The typical error message is:
|C:\...\lib\gcc\x86_64-w64-mingw32\7.2.0\include\c++\cstdlib:75:
error: stdlib.h: No such file or directory|
|at #include_next
|
|
|
||
The following bug report against GCC describes the same issue
independently of CMake, and apparently no improvement is to be
expected from the compiler itself:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129
So I rolled up my sleeves and implemented the following solution in
CMake. It calls the preprocessor to get the standard include search
paths and adds them to CMAKE_C_IMPLICIT_INCLUDE_DIRECTORIES and
CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES.
When a project or an external component tries to add them, CMake
ignores this, and the search order stays unharmed.
if("${CMAKE_MINGW_IMPLICIT_INCLUDE_DIRECTORIES}" STREQUAL "")
# Run the preprocessor in verbose mode on an empty input
execute_process(
COMMAND
"${CMAKE_CXX_COMPILER}"
"-E"
"-Wp,-v"
"-"
INPUT_FILE "NUL" # Special Windows file, equivalent to /dev/null
OUTPUT_VARIABLE _mingw_cpp_out # Capture stdout
ERROR_VARIABLE _mingw_cpp_error # Capture stderr
)
# Create list of lines from stderr output:
string(REGEX REPLACE ";" ";" _mingw_cpp_error
"${_mingw_cpp_error}")
string(REGEX REPLACE "\n" ";" _mingw_cpp_error "${_mingw_cpp_error}")
# Look for this text block and gather the paths:
# #include search starts here:
# C://bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/include
# C://bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/include-fixed
#
C://bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/../../../../x86_64-w64-mingw32/include
# End of search list.
set(_mingw_cpp_list)
foreach(_mingw_cpp_line ${_mingw_cpp_error})
if("${_mingw_cpp_line}" MATCHES "#include search starts here:")
# Block starts
set(_mingw_cpp_state "ON")
elseif("${_mingw_cpp_line}" MATCHES "End of search list.")
# Block ends
set(_mingw_cpp_state "OFF")
elseif("${_mingw_cpp_state}")
# Within block
# Clean up and beautify the path
string(STRIP "${_mingw_cpp_line}" _mingw_cpp_line)
get_filename_component(_mingw_cpp_line ${_mingw_cpp_line}
REALPATH)
list(APPEND _mingw_cpp_list ${_mingw_cpp_line})
endif()
endforeach()
# Set the list in the cache, so that we don't have to run the
external process again
set(CMAKE_MINGW_IMPLICIT_INCLUDE_DIRECTORIES ${_mingw_cpp_list}
CACHE INTERNAL "List of MinGW system include paths")
endif()
list(APPEND CMAKE_C_IMPLICIT_INCLUDE_DIRECTORIES
${CMAKE_MINGW_IMPLICIT_INCLUDE_DIRECTORIES})
list(APPEND CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES
${CMAKE_MINGW_IMPLICIT_INCLUDE_DIRECTORIES})
My question is: shouldn't this be done within the standard CMake
distribution, when using any GCC based compiler?
Olivier
--
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.13.0-rc3-348-g4193430
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 4193430628757eb664f65bb1810ce5077f68e2b3 (commit) from 71db32660eed1f70c06b624e661f8f5c2b938907 (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=4193430628757eb664f65bb1810ce5077f68e2b3 commit 4193430628757eb664f65bb1810ce5077f68e2b3 Author: Kitware Robot AuthorDate: Thu Nov 8 00:01:08 2018 -0500 Commit: Kitware Robot CommitDate: Thu Nov 8 00:01:08 2018 -0500 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index ad29c57..5f7dd8a 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 13) -set(CMake_VERSION_PATCH 20181107) +set(CMake_VERSION_PATCH 20181108) #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
[CMake] Using cmake-gui with Codeblocks
Hello, I can use cmake-gui successfully with “Visual Studio 15 2017 Win64,” but am not successful with using “Codeblocks – Nmake Makefiles.” I can use both successfully from the commandline to make Makrfiles. Does cmake-gui work with codeblocks? If it does, can somebody suggest some documentation that focuses on how to use cmake with codeblocks. The tutorial samples, that I have tried using, skip-over addressing codeblocks. Regards, Frank Sent from Mail for Windows 10 -- 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] Link order (Ubuntu)
I finally found this hack:
target_link_libraries(MyExe B $ ImpLib)
so I'm forcing the 'A' dependency to appear before the ImpLib.
Note that if I use:
target_link_libraries(MyExe B A ImpLib)
it does not work. I think it's because Cmake it's internally erasing
unnecessary dependencies.
Hope it helps other developers.
Il giorno mer 7 nov 2018 alle ore 19:10 Bo Zhou
ha scritto:
> Oh, if that's shared libraries, maybe you have to setup the
> LD_LIBRARY_PATH well for the shared libraries before linking, it just
> allows the linker to be able to locate the all necessary dynamic libraries
> during the linking. It happens sometimes on Linux, but not exists on OSX
> and Windows.
>
> On Tue, Nov 6, 2018 at 11:19 PM Giorgio Scorzelli
> wrote:
>
>> Thanks for you help.
>>
>> They are really shared lib, not static. I know it sounds weird: it's a
>> python extension which must not link the ${PYTHON_LIBRARY} (according to
>> official docs; in fact If I do so I get a segmentation fault) but finally
>> in my executable,a sort of custom/home made ${PYTHON_EXECUTABLE}, I have
>> to link the ${PYTHON_LIBRARY}.
>>
>> About the "B;A;ImportedExtLib;B;A" order. I agree too: it SHOULD work.
>> Let's say I do:
>>
>> target_link_libraries(MyExe B A ImpLib)
>>
>> in command line (make VERBOSE=1) I;m getting
>>
>> g++ -o MyExe B A ImpLib A
>>
>> The last "A" is coming from target_link_libraries(B PUBLIC A) and the
>> linker is complaining that this last "A" has undefined symbols.
>>
>> Thanks.Giorgio.
>>
>>
>>
>>
>>
>>
>>
>>
>> Il giorno mar 6 nov 2018 alle ore 06:59 Robert Maynard <
>> robert.mayn...@kitware.com> ha scritto:
>>
>>> You have order dependent static libraries which can be solved by
>>> constructing a cycle. As Bo stated by constructing the cycle
>>> B;A;ImportedExtLib;B;A each library can see each other.
>>>
>>> Looking at your original code example it looks like you are importing
>>> the libraries as SHARED, but I think these are actually static
>>> libraries and should be imported as such so that CMake does the
>>> automatic cycle creation. In general CMake doesn't do cycle creation
>>> for shared libraries as they are not link order dependent.
>>> On Tue, Nov 6, 2018 at 8:51 AM Giorgio Scorzelli
>>> wrote:
>>> >
>>> > I read the docs about LINK_INTERFACE_MULTIPLICITYtoo.
>>> > But I'm not in the situation of a "cyclic dependency" so I 'm not sure
>>> if it solve my problem.
>>> > In my case (with B A and ImpLib) what would be the syntax?
>>> >
>>> > Il giorno mar 6 nov 2018 alle ore 06:30 Robert Maynard <
>>> robert.mayn...@kitware.com> ha scritto:
>>> >>
>>> >> The target_link_libraries has a property called
>>> >> LINK_INTERFACE_MULTIPLICITY that should help you out.
>>> >>
>>> https://cmake.org/cmake/help/v3.13/command/target_link_libraries.html#cyclic-dependencies-of-static-libraries
>>> >>
>>> >>
>>> >> On Tue, Nov 6, 2018 at 8:24 AM scrgiorgio
>>> wrote:
>>> >> >
>>> >> > Thanks for the help,
>>> >> >
>>> >> > trying this (or any combination):
>>> >> >
>>> >> > target_link_libraries(MyExe B)
>>> >> > target_link_libraries(MyExe A )
>>> >> > target_link_libraries(MyExe ImpLib)
>>> >> >
>>> >> > I get this order:
>>> >> >
>>> >> > 'B;...whatever...;A;ImpLib"
>>> >> >
>>> >> > and the last past is causing the problem. Apparently there is no
>>> way to
>>> >> > change the right part (-Wl,--start-group -Wl,--end-groun sometimes
>>> work,
>>> >> > sometimes not).
>>> >> > Any advice?
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> > --
>>> >> > Sent from: http://cmake.3232098.n2.nabble.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
>>>
>> --
>>
>> 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] Link order (Ubuntu)
Oh, if that's shared libraries, maybe you have to setup the LD_LIBRARY_PATH
well for the shared libraries before linking, it just allows the linker to
be able to locate the all necessary dynamic libraries during the linking.
It happens sometimes on Linux, but not exists on OSX and Windows.
On Tue, Nov 6, 2018 at 11:19 PM Giorgio Scorzelli
wrote:
> Thanks for you help.
>
> They are really shared lib, not static. I know it sounds weird: it's a
> python extension which must not link the ${PYTHON_LIBRARY} (according to
> official docs; in fact If I do so I get a segmentation fault) but finally
> in my executable,a sort of custom/home made ${PYTHON_EXECUTABLE}, I have
> to link the ${PYTHON_LIBRARY}.
>
> About the "B;A;ImportedExtLib;B;A" order. I agree too: it SHOULD work.
> Let's say I do:
>
> target_link_libraries(MyExe B A ImpLib)
>
> in command line (make VERBOSE=1) I;m getting
>
> g++ -o MyExe B A ImpLib A
>
> The last "A" is coming from target_link_libraries(B PUBLIC A) and the
> linker is complaining that this last "A" has undefined symbols.
>
> Thanks.Giorgio.
>
>
>
>
>
>
>
>
> Il giorno mar 6 nov 2018 alle ore 06:59 Robert Maynard <
> robert.mayn...@kitware.com> ha scritto:
>
>> You have order dependent static libraries which can be solved by
>> constructing a cycle. As Bo stated by constructing the cycle
>> B;A;ImportedExtLib;B;A each library can see each other.
>>
>> Looking at your original code example it looks like you are importing
>> the libraries as SHARED, but I think these are actually static
>> libraries and should be imported as such so that CMake does the
>> automatic cycle creation. In general CMake doesn't do cycle creation
>> for shared libraries as they are not link order dependent.
>> On Tue, Nov 6, 2018 at 8:51 AM Giorgio Scorzelli
>> wrote:
>> >
>> > I read the docs about LINK_INTERFACE_MULTIPLICITYtoo.
>> > But I'm not in the situation of a "cyclic dependency" so I 'm not sure
>> if it solve my problem.
>> > In my case (with B A and ImpLib) what would be the syntax?
>> >
>> > Il giorno mar 6 nov 2018 alle ore 06:30 Robert Maynard <
>> robert.mayn...@kitware.com> ha scritto:
>> >>
>> >> The target_link_libraries has a property called
>> >> LINK_INTERFACE_MULTIPLICITY that should help you out.
>> >>
>> https://cmake.org/cmake/help/v3.13/command/target_link_libraries.html#cyclic-dependencies-of-static-libraries
>> >>
>> >>
>> >> On Tue, Nov 6, 2018 at 8:24 AM scrgiorgio
>> wrote:
>> >> >
>> >> > Thanks for the help,
>> >> >
>> >> > trying this (or any combination):
>> >> >
>> >> > target_link_libraries(MyExe B)
>> >> > target_link_libraries(MyExe A )
>> >> > target_link_libraries(MyExe ImpLib)
>> >> >
>> >> > I get this order:
>> >> >
>> >> > 'B;...whatever...;A;ImpLib"
>> >> >
>> >> > and the last past is causing the problem. Apparently there is no way
>> to
>> >> > change the right part (-Wl,--start-group -Wl,--end-groun sometimes
>> work,
>> >> > sometimes not).
>> >> > Any advice?
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Sent from: http://cmake.3232098.n2.nabble.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
>>
> --
>
> 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
Re: [CMake] Uninstalling CMake from Linux?
On 2018-11-07 22:48- Osman Zakir wrote: I want to remove CMake from my Docker image in order to reduce the image size (I'm also going to remove g++, make and build-essential -- it's after the executable program has been built). How do I do this? My opinion is this question is off-topic for this list. Instead consult with some appropriate Docker list. Alan __ Alan W. Irwin 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 __ -- 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] Uninstalling CMake from Linux?
I want to remove CMake from my Docker image in order to reduce the image size (I'm also going to remove g++, make and build-essential -- it's after the executable program has been built). How do I do this? -- 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] LOCATION/CMP0026/export/import
Ok, that works for us! On Wed, Nov 7, 2018 at 2:29 PM Robert Maynard wrote: > Yes you can get if a target is imported by seeing if the IMPORTED > property is set to true. ( > https://cmake.org/cmake/help/v3.12/prop_tgt/IMPORTED.html ) > On Wed, Nov 7, 2018 at 5:24 PM Hendrik Greving > wrote: > > > > Ok, it seems to be IMPORT_LOCATION, not IMPORTED_LOCATION > > We have a (.cmake) file that shared among things that use it for build > targets and external projects for imported targets. Is there a way to find > out whether a target is imported or a build target? > > > > > > On Wed, Nov 7, 2018 at 2:19 PM Robert Maynard < > robert.mayn...@kitware.com> wrote: > >> > >> I am not seeing any cmake errors/warnings when I do so :) > >> On Wed, Nov 7, 2018 at 5:15 PM Hendrik Greving > >> wrote: > >> > > >> > Ok! Except (see above) I do not think one can actually read > IMPORTED_LOCATION, can I? > >> > Thanks! - again! > >> > > >> > On Wed, Nov 7, 2018 at 2:07 PM Robert Maynard < > robert.mayn...@kitware.com> wrote: > >> >> > >> >> Looking at CMP0026 more, I believe should be able to read either the > >> >> IMPORTED_LOCATION or LOCATION for any import target without > triggering > >> >> the policy, as the policy only pertains to 'build' targets and not > >> >> 'import' targets. > >> >> On Wed, Nov 7, 2018 at 4:51 PM Hendrik Greving > >> >> wrote: > >> >> > > >> >> > Is IMPORTED_LOCATION a property one can read? I was under the > assumption that setting IMPORTED_LOCATION becomes LOCATION (for imported > targets). And as such, reading this LOCATION generates the warning. I just > tried and it indeed didn't let me read IMPORTED_LOCATION. > >> >> > > >> >> > On Wed, Nov 7, 2018 at 12:36 PM Robert Maynard < > robert.mayn...@kitware.com> wrote: > >> >> >> > >> >> >> I believe that IMPORTED_LOCATION is safe to use. > >> >> >> On Wed, Nov 7, 2018 at 3:27 PM Hendrik Greving > >> >> >> wrote: > >> >> >> > > >> >> >> > So IMPORTED_LOCATION is obsolete as well? (since reading > LOCATION is obsolete) > >> >> >> > > >> >> >> > On Wed, Nov 7, 2018 at 11:39 AM Robert Maynard < > robert.mayn...@kitware.com> wrote: > >> >> >> >> > >> >> >> >> With generator expressions making the reading of LOCATION > non-viable > >> >> >> >> during configuration time ( since the actual location is now > evaluated > >> >> >> >> at generate time ), the general solution is that you need to > move your > >> >> >> >> LOCATION reading logic also to generate time. In general this > means > >> >> >> >> using something like file(GENERATE ) to dump the location to > disk. > >> >> >> >> On Wed, Nov 7, 2018 at 1:05 PM Hendrik Greving > >> >> >> >> wrote: > >> >> >> >> > > >> >> >> >> > Hello, > >> >> >> >> > > >> >> >> >> > w/ LOCATION property made obsolete, how can one read a > target's LOCATION for imported targets? Previously, IMPORTED_LOCATION was > conveyed for such targets, but reading the LOCATION property of imported > targets leads to the same warning as for project targets? > >> >> >> >> > > >> >> >> >> > Thanks in advance > >> >> >> >> > -- > >> >> >> >> > > >> >> >> >> > 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] LOCATION/CMP0026/export/import
Yes you can get if a target is imported by seeing if the IMPORTED property is set to true. ( https://cmake.org/cmake/help/v3.12/prop_tgt/IMPORTED.html ) On Wed, Nov 7, 2018 at 5:24 PM Hendrik Greving wrote: > > Ok, it seems to be IMPORT_LOCATION, not IMPORTED_LOCATION > We have a (.cmake) file that shared among things that use it for build > targets and external projects for imported targets. Is there a way to find > out whether a target is imported or a build target? > > > On Wed, Nov 7, 2018 at 2:19 PM Robert Maynard > wrote: >> >> I am not seeing any cmake errors/warnings when I do so :) >> On Wed, Nov 7, 2018 at 5:15 PM Hendrik Greving >> wrote: >> > >> > Ok! Except (see above) I do not think one can actually read >> > IMPORTED_LOCATION, can I? >> > Thanks! - again! >> > >> > On Wed, Nov 7, 2018 at 2:07 PM Robert Maynard >> > wrote: >> >> >> >> Looking at CMP0026 more, I believe should be able to read either the >> >> IMPORTED_LOCATION or LOCATION for any import target without triggering >> >> the policy, as the policy only pertains to 'build' targets and not >> >> 'import' targets. >> >> On Wed, Nov 7, 2018 at 4:51 PM Hendrik Greving >> >> wrote: >> >> > >> >> > Is IMPORTED_LOCATION a property one can read? I was under the >> >> > assumption that setting IMPORTED_LOCATION becomes LOCATION (for >> >> > imported targets). And as such, reading this LOCATION generates the >> >> > warning. I just tried and it indeed didn't let me read >> >> > IMPORTED_LOCATION. >> >> > >> >> > On Wed, Nov 7, 2018 at 12:36 PM Robert Maynard >> >> > wrote: >> >> >> >> >> >> I believe that IMPORTED_LOCATION is safe to use. >> >> >> On Wed, Nov 7, 2018 at 3:27 PM Hendrik Greving >> >> >> wrote: >> >> >> > >> >> >> > So IMPORTED_LOCATION is obsolete as well? (since reading LOCATION is >> >> >> > obsolete) >> >> >> > >> >> >> > On Wed, Nov 7, 2018 at 11:39 AM Robert Maynard >> >> >> > wrote: >> >> >> >> >> >> >> >> With generator expressions making the reading of LOCATION >> >> >> >> non-viable >> >> >> >> during configuration time ( since the actual location is now >> >> >> >> evaluated >> >> >> >> at generate time ), the general solution is that you need to move >> >> >> >> your >> >> >> >> LOCATION reading logic also to generate time. In general this means >> >> >> >> using something like file(GENERATE ) to dump the location to disk. >> >> >> >> On Wed, Nov 7, 2018 at 1:05 PM Hendrik Greving >> >> >> >> wrote: >> >> >> >> > >> >> >> >> > Hello, >> >> >> >> > >> >> >> >> > w/ LOCATION property made obsolete, how can one read a target's >> >> >> >> > LOCATION for imported targets? Previously, IMPORTED_LOCATION was >> >> >> >> > conveyed for such targets, but reading the LOCATION property of >> >> >> >> > imported targets leads to the same warning as for project targets? >> >> >> >> > >> >> >> >> > Thanks in advance >> >> >> >> > -- >> >> >> >> > >> >> >> >> > 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] LOCATION/CMP0026/export/import
Ok, it seems to be IMPORT_LOCATION, not IMPORTED_LOCATION We have a (.cmake) file that shared among things that use it for build targets and external projects for imported targets. Is there a way to find out whether a target is imported or a build target? On Wed, Nov 7, 2018 at 2:19 PM Robert Maynard wrote: > I am not seeing any cmake errors/warnings when I do so :) > On Wed, Nov 7, 2018 at 5:15 PM Hendrik Greving > wrote: > > > > Ok! Except (see above) I do not think one can actually read > IMPORTED_LOCATION, can I? > > Thanks! - again! > > > > On Wed, Nov 7, 2018 at 2:07 PM Robert Maynard < > robert.mayn...@kitware.com> wrote: > >> > >> Looking at CMP0026 more, I believe should be able to read either the > >> IMPORTED_LOCATION or LOCATION for any import target without triggering > >> the policy, as the policy only pertains to 'build' targets and not > >> 'import' targets. > >> On Wed, Nov 7, 2018 at 4:51 PM Hendrik Greving > >> wrote: > >> > > >> > Is IMPORTED_LOCATION a property one can read? I was under the > assumption that setting IMPORTED_LOCATION becomes LOCATION (for imported > targets). And as such, reading this LOCATION generates the warning. I just > tried and it indeed didn't let me read IMPORTED_LOCATION. > >> > > >> > On Wed, Nov 7, 2018 at 12:36 PM Robert Maynard < > robert.mayn...@kitware.com> wrote: > >> >> > >> >> I believe that IMPORTED_LOCATION is safe to use. > >> >> On Wed, Nov 7, 2018 at 3:27 PM Hendrik Greving > >> >> wrote: > >> >> > > >> >> > So IMPORTED_LOCATION is obsolete as well? (since reading LOCATION > is obsolete) > >> >> > > >> >> > On Wed, Nov 7, 2018 at 11:39 AM Robert Maynard < > robert.mayn...@kitware.com> wrote: > >> >> >> > >> >> >> With generator expressions making the reading of LOCATION > non-viable > >> >> >> during configuration time ( since the actual location is now > evaluated > >> >> >> at generate time ), the general solution is that you need to move > your > >> >> >> LOCATION reading logic also to generate time. In general this > means > >> >> >> using something like file(GENERATE ) to dump the location to disk. > >> >> >> On Wed, Nov 7, 2018 at 1:05 PM Hendrik Greving > >> >> >> wrote: > >> >> >> > > >> >> >> > Hello, > >> >> >> > > >> >> >> > w/ LOCATION property made obsolete, how can one read a target's > LOCATION for imported targets? Previously, IMPORTED_LOCATION was conveyed > for such targets, but reading the LOCATION property of imported targets > leads to the same warning as for project targets? > >> >> >> > > >> >> >> > Thanks in advance > >> >> >> > -- > >> >> >> > > >> >> >> > 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] LOCATION/CMP0026/export/import
I am not seeing any cmake errors/warnings when I do so :) On Wed, Nov 7, 2018 at 5:15 PM Hendrik Greving wrote: > > Ok! Except (see above) I do not think one can actually read > IMPORTED_LOCATION, can I? > Thanks! - again! > > On Wed, Nov 7, 2018 at 2:07 PM Robert Maynard > wrote: >> >> Looking at CMP0026 more, I believe should be able to read either the >> IMPORTED_LOCATION or LOCATION for any import target without triggering >> the policy, as the policy only pertains to 'build' targets and not >> 'import' targets. >> On Wed, Nov 7, 2018 at 4:51 PM Hendrik Greving >> wrote: >> > >> > Is IMPORTED_LOCATION a property one can read? I was under the assumption >> > that setting IMPORTED_LOCATION becomes LOCATION (for imported targets). >> > And as such, reading this LOCATION generates the warning. I just tried and >> > it indeed didn't let me read IMPORTED_LOCATION. >> > >> > On Wed, Nov 7, 2018 at 12:36 PM Robert Maynard >> > wrote: >> >> >> >> I believe that IMPORTED_LOCATION is safe to use. >> >> On Wed, Nov 7, 2018 at 3:27 PM Hendrik Greving >> >> wrote: >> >> > >> >> > So IMPORTED_LOCATION is obsolete as well? (since reading LOCATION is >> >> > obsolete) >> >> > >> >> > On Wed, Nov 7, 2018 at 11:39 AM Robert Maynard >> >> > wrote: >> >> >> >> >> >> With generator expressions making the reading of LOCATION non-viable >> >> >> during configuration time ( since the actual location is now evaluated >> >> >> at generate time ), the general solution is that you need to move your >> >> >> LOCATION reading logic also to generate time. In general this means >> >> >> using something like file(GENERATE ) to dump the location to disk. >> >> >> On Wed, Nov 7, 2018 at 1:05 PM Hendrik Greving >> >> >> wrote: >> >> >> > >> >> >> > Hello, >> >> >> > >> >> >> > w/ LOCATION property made obsolete, how can one read a target's >> >> >> > LOCATION for imported targets? Previously, IMPORTED_LOCATION was >> >> >> > conveyed for such targets, but reading the LOCATION property of >> >> >> > imported targets leads to the same warning as for project targets? >> >> >> > >> >> >> > Thanks in advance >> >> >> > -- >> >> >> > >> >> >> > 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] LOCATION/CMP0026/export/import
Ok! Except (see above) I do not think one can actually read IMPORTED_LOCATION, can I? Thanks! - again! On Wed, Nov 7, 2018 at 2:07 PM Robert Maynard wrote: > Looking at CMP0026 more, I believe should be able to read either the > IMPORTED_LOCATION or LOCATION for any import target without triggering > the policy, as the policy only pertains to 'build' targets and not > 'import' targets. > On Wed, Nov 7, 2018 at 4:51 PM Hendrik Greving > wrote: > > > > Is IMPORTED_LOCATION a property one can read? I was under the assumption > that setting IMPORTED_LOCATION becomes LOCATION (for imported targets). And > as such, reading this LOCATION generates the warning. I just tried and it > indeed didn't let me read IMPORTED_LOCATION. > > > > On Wed, Nov 7, 2018 at 12:36 PM Robert Maynard < > robert.mayn...@kitware.com> wrote: > >> > >> I believe that IMPORTED_LOCATION is safe to use. > >> On Wed, Nov 7, 2018 at 3:27 PM Hendrik Greving > >> wrote: > >> > > >> > So IMPORTED_LOCATION is obsolete as well? (since reading LOCATION is > obsolete) > >> > > >> > On Wed, Nov 7, 2018 at 11:39 AM Robert Maynard < > robert.mayn...@kitware.com> wrote: > >> >> > >> >> With generator expressions making the reading of LOCATION non-viable > >> >> during configuration time ( since the actual location is now > evaluated > >> >> at generate time ), the general solution is that you need to move > your > >> >> LOCATION reading logic also to generate time. In general this means > >> >> using something like file(GENERATE ) to dump the location to disk. > >> >> On Wed, Nov 7, 2018 at 1:05 PM Hendrik Greving > >> >> wrote: > >> >> > > >> >> > Hello, > >> >> > > >> >> > w/ LOCATION property made obsolete, how can one read a target's > LOCATION for imported targets? Previously, IMPORTED_LOCATION was conveyed > for such targets, but reading the LOCATION property of imported targets > leads to the same warning as for project targets? > >> >> > > >> >> > Thanks in advance > >> >> > -- > >> >> > > >> >> > 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] LOCATION/CMP0026/export/import
Looking at CMP0026 more, I believe should be able to read either the IMPORTED_LOCATION or LOCATION for any import target without triggering the policy, as the policy only pertains to 'build' targets and not 'import' targets. On Wed, Nov 7, 2018 at 4:51 PM Hendrik Greving wrote: > > Is IMPORTED_LOCATION a property one can read? I was under the assumption that > setting IMPORTED_LOCATION becomes LOCATION (for imported targets). And as > such, reading this LOCATION generates the warning. I just tried and it indeed > didn't let me read IMPORTED_LOCATION. > > On Wed, Nov 7, 2018 at 12:36 PM Robert Maynard > wrote: >> >> I believe that IMPORTED_LOCATION is safe to use. >> On Wed, Nov 7, 2018 at 3:27 PM Hendrik Greving >> wrote: >> > >> > So IMPORTED_LOCATION is obsolete as well? (since reading LOCATION is >> > obsolete) >> > >> > On Wed, Nov 7, 2018 at 11:39 AM Robert Maynard >> > wrote: >> >> >> >> With generator expressions making the reading of LOCATION non-viable >> >> during configuration time ( since the actual location is now evaluated >> >> at generate time ), the general solution is that you need to move your >> >> LOCATION reading logic also to generate time. In general this means >> >> using something like file(GENERATE ) to dump the location to disk. >> >> On Wed, Nov 7, 2018 at 1:05 PM Hendrik Greving >> >> wrote: >> >> > >> >> > Hello, >> >> > >> >> > w/ LOCATION property made obsolete, how can one read a target's >> >> > LOCATION for imported targets? Previously, IMPORTED_LOCATION was >> >> > conveyed for such targets, but reading the LOCATION property of >> >> > imported targets leads to the same warning as for project targets? >> >> > >> >> > Thanks in advance >> >> > -- >> >> > >> >> > 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] LOCATION/CMP0026/export/import
Is IMPORTED_LOCATION a property one can read? I was under the assumption that setting IMPORTED_LOCATION becomes LOCATION (for imported targets). And as such, reading this LOCATION generates the warning. I just tried and it indeed didn't let me read IMPORTED_LOCATION. On Wed, Nov 7, 2018 at 12:36 PM Robert Maynard wrote: > I believe that IMPORTED_LOCATION is safe to use. > On Wed, Nov 7, 2018 at 3:27 PM Hendrik Greving > wrote: > > > > So IMPORTED_LOCATION is obsolete as well? (since reading LOCATION is > obsolete) > > > > On Wed, Nov 7, 2018 at 11:39 AM Robert Maynard < > robert.mayn...@kitware.com> wrote: > >> > >> With generator expressions making the reading of LOCATION non-viable > >> during configuration time ( since the actual location is now evaluated > >> at generate time ), the general solution is that you need to move your > >> LOCATION reading logic also to generate time. In general this means > >> using something like file(GENERATE ) to dump the location to disk. > >> On Wed, Nov 7, 2018 at 1:05 PM Hendrik Greving > >> wrote: > >> > > >> > Hello, > >> > > >> > w/ LOCATION property made obsolete, how can one read a target's > LOCATION for imported targets? Previously, IMPORTED_LOCATION was conveyed > for such targets, but reading the LOCATION property of imported targets > leads to the same warning as for project targets? > >> > > >> > Thanks in advance > >> > -- > >> > > >> > 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] LOCATION/CMP0026/export/import
I believe that IMPORTED_LOCATION is safe to use. On Wed, Nov 7, 2018 at 3:27 PM Hendrik Greving wrote: > > So IMPORTED_LOCATION is obsolete as well? (since reading LOCATION is obsolete) > > On Wed, Nov 7, 2018 at 11:39 AM Robert Maynard > wrote: >> >> With generator expressions making the reading of LOCATION non-viable >> during configuration time ( since the actual location is now evaluated >> at generate time ), the general solution is that you need to move your >> LOCATION reading logic also to generate time. In general this means >> using something like file(GENERATE ) to dump the location to disk. >> On Wed, Nov 7, 2018 at 1:05 PM Hendrik Greving >> wrote: >> > >> > Hello, >> > >> > w/ LOCATION property made obsolete, how can one read a target's LOCATION >> > for imported targets? Previously, IMPORTED_LOCATION was conveyed for such >> > targets, but reading the LOCATION property of imported targets leads to >> > the same warning as for project targets? >> > >> > Thanks in advance >> > -- >> > >> > 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] LOCATION/CMP0026/export/import
So IMPORTED_LOCATION is obsolete as well? (since reading LOCATION is obsolete) On Wed, Nov 7, 2018 at 11:39 AM Robert Maynard wrote: > With generator expressions making the reading of LOCATION non-viable > during configuration time ( since the actual location is now evaluated > at generate time ), the general solution is that you need to move your > LOCATION reading logic also to generate time. In general this means > using something like file(GENERATE ) to dump the location to disk. > On Wed, Nov 7, 2018 at 1:05 PM Hendrik Greving > wrote: > > > > Hello, > > > > w/ LOCATION property made obsolete, how can one read a target's LOCATION > for imported targets? Previously, IMPORTED_LOCATION was conveyed for such > targets, but reading the LOCATION property of imported targets leads to the > same warning as for project targets? > > > > Thanks in advance > > -- > > > > 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] Why is obj.dir/depend.make.tmp not renamed to obj.dir/depend.make?
Did cmake finish to completion when generating the Makefiles? On Wed, Nov 7, 2018 at 11:46 AM Steffen Dettmer wrote: > Hi, > > One (of really many) build trees contains a file "depend.make.tmp" and > ignores dependencies leading to broken (incremental) builds. There > also is a "depend.make" file in the same directory saying "Empty > dependencies file. This may be replaced when dependencies are built.", > so I assume the tmp file should be rename to it. The timestamp of the > tmp file is newer. I like to understand the cause and how to solve it. > I did not find any makefile rule that should do the rename. > > The problem became visible in form of a SIGSEGV of a test application. > Analysing this down to the "depend.make.tmp" issue took quite a bit of > time, so I like to understand the root cause and learn how to avoid > it. Since only one build tree seems to be affected it seems to be a > very rare issue, maybe a race condition or such. > > Any suggestions how I could analyse further? > > Steffen > -- > > 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] LOCATION/CMP0026/export/import
With generator expressions making the reading of LOCATION non-viable during configuration time ( since the actual location is now evaluated at generate time ), the general solution is that you need to move your LOCATION reading logic also to generate time. In general this means using something like file(GENERATE ) to dump the location to disk. On Wed, Nov 7, 2018 at 1:05 PM Hendrik Greving wrote: > > Hello, > > w/ LOCATION property made obsolete, how can one read a target's LOCATION for > imported targets? Previously, IMPORTED_LOCATION was conveyed for such > targets, but reading the LOCATION property of imported targets leads to the > same warning as for project targets? > > Thanks in advance > -- > > 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
[CMake] LOCATION/CMP0026/export/import
Hello, w/ LOCATION property made obsolete, how can one read a target's LOCATION for imported targets? Previously, IMPORTED_LOCATION was conveyed for such targets, but reading the LOCATION property of imported targets leads to the same warning as for project targets? Thanks in advance -- 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] How to instruct CMAKE not to generate a .lib for the target .exe
I have a very simple CMAKE to generate a .exe target (say xyz.exe) with several .cpp source files and some external .lib files (boost and wxwidgets). For some reason, CMAKE generates a .lib for the target (xyz.lib) and then generate the .exe (xyz.exe) using the /IMPLIB liner option to pull in the xyz.lib file. Is there a way to instruct CMAKE not to generate the .lib (xyz.lib) but only to generate the .obj (xyz.obj) before performing the link operation? Thanks in advance for your help. -- 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-developers] [ANNOUNCE] CMake 3.13.0-rc3 is ready for testing
I am proud to announce the third CMake 3.13 release candidate. https://cmake.org/download/ The first 3.13.0 release candidates included a change to allow generator expressions in "install(CODE)" and "install(SCRIPT)". This has been reverted in rc2 due to breaking backwards compatibility. See issue #18435. Documentation is available at: https://cmake.org/cmake/help/v3.13 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.13/release/3.13.html Some of the more significant changes in CMake 3.13 are: * The Visual Studio Generators for VS 2010 and above learned to support the "INTERPROCEDURAL_OPTIMIZATION" target property and supporting "CheckIPOSupported" module. * The "Green Hills MULTI" generator has been updated to include support for platform, architecture, and toolset selection. * The "cmake" command gained the "-S " command line option to specify the location of the source directory. This option can be used independently of "-B". * The "cmake" command gained the "-B " command line option to specify the location of the build directory. This option can be used independently of "-S". * The "cmake" "-E create_symlink" command can now be used on Windows. * The "target_link_directories()" command was created to specify link directories for targets and their dependents. * The "target_link_options()" command was created to specify link options for targets and their dependents. * The "target_link_libraries()" command may now be called to modify targets created outside the current directory. See policy "CMP0079". * The "install(TARGETS)" command learned to install targets created outside the current directory. * A "VS_DEBUGGER_COMMAND_ARGUMENTS" target property was created to set the debugging command line arguments with Visual Studio Generators for VS 2010 and above. * A "VS_DEBUGGER_ENVIRONMENT" target property was created to set the debugging environment with Visual Studio Generators for VS 2010 and above. * The "option()" command now honors an existing normal variable of the same name and does nothing instead of possibly creating a cache entry (or setting its type) and removing the normal variable. See policy "CMP0077". * The "target_sources()" command now interprets relative source file paths as relative to the current source directory. This simplifies incrementally building up a target's sources from subdirectories. The "CMP0076" policy was added to provide backward compatibility with the old behavior where required. CMake 3.13 Release Notes Changes made since CMake 3.12 include the following. New Features Generators -- * The Visual Studio Generators for VS 2010 and above learned to support the "INTERPROCEDURAL_OPTIMIZATION" target property and supporting "CheckIPOSupported" module. * The "Xcode" generator learned to configure more Xcode Scheme fields. See the "CMAKE_XCODE_GENERATE_SCHEME" variable. * The "Green Hills MULTI" generator has been updated: * Added support for architecture selection through "CMAKE_GENERATOR_PLATFORM": e.g. "arm", "ppc", and "86". * Added support for toolset selection through "CMAKE_GENERATOR_TOOLSET", e.g. "comp_201205", "comp_201510", "comp_201722_beta". * Added support for platform selection through "GHS_TARGET_PLATFORM", e.g. "integrity", "linux", "standalone", etc. * No longer checks that "arm" based compilers are installed but ensures that the correct "gbuild.exe" exists. * No longer hard-codes ARM files, BSP, toolset, or OS locations. Command-Line * The "cmake(1)" command gained the "-S " command line option to specify the location of the source directory. This option can be used independently of "-B". * The "cmake(1)" command gained the "-B " command line option to specify the location of the build directory. This option can be used independently of "-S". * The "cmake(1)" "-E create_symlink" command can now be used on Windows. Commands * The "add_custom_command()" and "add_custom_target()" commands learned to support generator expressions in "WORKING_DIRECTORY" options. * The "add_link_options()" command was created to add link options in the current directory. * The "install(TARGETS)" command learned to install targets created outside the current directory. * The "link_directories()" command gained options to control insertion position. * The "list(SORT)" command gained options to control the comparison operation used to order the entries. * The "math()" command gained options for hexadecimal. * The "target_link_directories()" command was created to specify link directories for targets and their dependents. * The "target_link_options()" command was created to specify link options for targets and their dependents. * The "target_link_libraries()" command may now be called to modify targets created outside
[CMake] [ANNOUNCE] CMake 3.13.0-rc3 is ready for testing
I am proud to announce the third CMake 3.13 release candidate. https://cmake.org/download/ The first 3.13.0 release candidates included a change to allow generator expressions in "install(CODE)" and "install(SCRIPT)". This has been reverted in rc2 due to breaking backwards compatibility. See issue #18435. Documentation is available at: https://cmake.org/cmake/help/v3.13 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.13/release/3.13.html Some of the more significant changes in CMake 3.13 are: * The Visual Studio Generators for VS 2010 and above learned to support the "INTERPROCEDURAL_OPTIMIZATION" target property and supporting "CheckIPOSupported" module. * The "Green Hills MULTI" generator has been updated to include support for platform, architecture, and toolset selection. * The "cmake" command gained the "-S " command line option to specify the location of the source directory. This option can be used independently of "-B". * The "cmake" command gained the "-B " command line option to specify the location of the build directory. This option can be used independently of "-S". * The "cmake" "-E create_symlink" command can now be used on Windows. * The "target_link_directories()" command was created to specify link directories for targets and their dependents. * The "target_link_options()" command was created to specify link options for targets and their dependents. * The "target_link_libraries()" command may now be called to modify targets created outside the current directory. See policy "CMP0079". * The "install(TARGETS)" command learned to install targets created outside the current directory. * A "VS_DEBUGGER_COMMAND_ARGUMENTS" target property was created to set the debugging command line arguments with Visual Studio Generators for VS 2010 and above. * A "VS_DEBUGGER_ENVIRONMENT" target property was created to set the debugging environment with Visual Studio Generators for VS 2010 and above. * The "option()" command now honors an existing normal variable of the same name and does nothing instead of possibly creating a cache entry (or setting its type) and removing the normal variable. See policy "CMP0077". * The "target_sources()" command now interprets relative source file paths as relative to the current source directory. This simplifies incrementally building up a target's sources from subdirectories. The "CMP0076" policy was added to provide backward compatibility with the old behavior where required. CMake 3.13 Release Notes Changes made since CMake 3.12 include the following. New Features Generators -- * The Visual Studio Generators for VS 2010 and above learned to support the "INTERPROCEDURAL_OPTIMIZATION" target property and supporting "CheckIPOSupported" module. * The "Xcode" generator learned to configure more Xcode Scheme fields. See the "CMAKE_XCODE_GENERATE_SCHEME" variable. * The "Green Hills MULTI" generator has been updated: * Added support for architecture selection through "CMAKE_GENERATOR_PLATFORM": e.g. "arm", "ppc", and "86". * Added support for toolset selection through "CMAKE_GENERATOR_TOOLSET", e.g. "comp_201205", "comp_201510", "comp_201722_beta". * Added support for platform selection through "GHS_TARGET_PLATFORM", e.g. "integrity", "linux", "standalone", etc. * No longer checks that "arm" based compilers are installed but ensures that the correct "gbuild.exe" exists. * No longer hard-codes ARM files, BSP, toolset, or OS locations. Command-Line * The "cmake(1)" command gained the "-S " command line option to specify the location of the source directory. This option can be used independently of "-B". * The "cmake(1)" command gained the "-B " command line option to specify the location of the build directory. This option can be used independently of "-S". * The "cmake(1)" "-E create_symlink" command can now be used on Windows. Commands * The "add_custom_command()" and "add_custom_target()" commands learned to support generator expressions in "WORKING_DIRECTORY" options. * The "add_link_options()" command was created to add link options in the current directory. * The "install(TARGETS)" command learned to install targets created outside the current directory. * The "link_directories()" command gained options to control insertion position. * The "list(SORT)" command gained options to control the comparison operation used to order the entries. * The "math()" command gained options for hexadecimal. * The "target_link_directories()" command was created to specify link directories for targets and their dependents. * The "target_link_options()" command was created to specify link options for targets and their dependents. * The "target_link_libraries()" command may now be called to modify targets created outside
[Cmake-commits] CMake branch, release, updated. v3.13.0-rc2-51-g8d70ed5
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 8d70ed5a10362209d265a15d993f319235aea7e5 (commit) from 3bad96c9888932ec2b792f2febfee6cc58bf8bbd (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: 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
[Cmake-commits] CMake branch, master, updated. v3.13.0-rc2-396-g48de916
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 48de9169d0624b323462c084b68cb1fdb693d91b (commit) via a67d1e824c162a7f84a1d2520199c7e5d10080fb (commit) via 3bad96c9888932ec2b792f2febfee6cc58bf8bbd (commit) via 272c4c3dee28a7b1c0a690cac3cb310165324794 (commit) via db0445f0c860cc561baf3b38f296b7f338385d63 (commit) from 7e6b78759904dcf31d780a6e2f14f3821f4f23df (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=48de9169d0624b323462c084b68cb1fdb693d91b commit 48de9169d0624b323462c084b68cb1fdb693d91b Merge: a67d1e8 3bad96c Author: Brad King AuthorDate: Wed Nov 7 07:49:38 2018 -0500 Commit: Brad King CommitDate: Wed Nov 7 07:49:38 2018 -0500 Merge branch 'release-3.13' https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a67d1e824c162a7f84a1d2520199c7e5d10080fb commit a67d1e824c162a7f84a1d2520199c7e5d10080fb Merge: 7e6b787 272c4c3 Author: Brad King AuthorDate: Wed Nov 7 12:46:33 2018 + Commit: Kitware Robot CommitDate: Wed Nov 7 07:46:40 2018 -0500 Merge topic 'FindOpenMP-log-errors' 272c4c3dee FindOpenMP: Log error output db0445f0c8 FindOpenMP: Fix warnings with -Wstrict-prototypes Acked-by: Kitware Robot Reviewed-by: Christian Pfeiffer Merge-request: !2574 --- Summary of changes: Modules/FindOpenMP.cmake | 13 ++--- 1 file changed, 10 insertions(+), 3 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org https://cmake.org/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, release, updated. v3.13.0-rc2-50-g3bad96c
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 3bad96c9888932ec2b792f2febfee6cc58bf8bbd (commit) via 272c4c3dee28a7b1c0a690cac3cb310165324794 (commit) via db0445f0c860cc561baf3b38f296b7f338385d63 (commit) from 263d28b2566facd87fe72dd40fc869fc09ca4172 (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/FindOpenMP.cmake | 13 ++--- 1 file changed, 10 insertions(+), 3 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.13.0-rc2-391-g7e6b787
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 7e6b78759904dcf31d780a6e2f14f3821f4f23df (commit) via cf78a7df952a8d7be4228cb1c4a4b38ebc63dae8 (commit) via bb8da283ce40d3bb06df348ea2820dd12213a2e1 (commit) via 389002de96fdabd05b709415712b1d8d8aa264b9 (commit) via fe40570608f43aade8f4262e9ca55d98a2b169fd (commit) via c67ab22cdc680f6322e558b4f2c7cc74b6dbe163 (commit) via 86c07b916557ac83cd77f6250d090fa45b4b9bc2 (commit) via ab1d7df7575503c8eabdf6f8892b5944b06d98e5 (commit) via e0f0f80f0286b7181b1203693799f5fcfcd8b4af (commit) via 2b2b41f038af97b7bca2213cda0198d2a28f6c2e (commit) via e045fb202ddf9100965ac418f4aa22e65256dd8d (commit) via 3fa0a03b7e4094bef1b66e48ed437e1c0b41c49a (commit) via fb423b3c49d21df851b1d4a91fddfe94d835155b (commit) via 867c9c9c0dc2782b2d822557c8dc83c451409b48 (commit) via a85e5e6f4d53dd158392dd74b9632d84fb583722 (commit) via ff1db47728a37a7775a3b870ff9ffdc3249c3d40 (commit) via fe8acf7c0540ca39300bab5b014e428e84077c7a (commit) via 9891adf74becfa95463f6928fda9f8ac17c934bd (commit) via 20b6561e78f5acceecae7c6fc330f7f7de4f2223 (commit) via 873e59c0c456c2e13e66019c15f3632d06dac0f6 (commit) via b2a798fe32ce25e5ea19f6487ce9cadf9852ea83 (commit) via db749f404c29bc91a06f2ea2fb23d8a30c526a9a (commit) via 53a5aec89998a58dff53946b47426ea692c5ad8d (commit) via f92f93467ecc22419c981f8f5283c81fa9d8eb01 (commit) from df542558c645f9a704fb5bcc2b2e304f6879ab35 (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=7e6b78759904dcf31d780a6e2f14f3821f4f23df commit 7e6b78759904dcf31d780a6e2f14f3821f4f23df Merge: cf78a7d c67ab22 Author: Brad King AuthorDate: Wed Nov 7 12:30:12 2018 + Commit: Kitware Robot CommitDate: Wed Nov 7 07:30:20 2018 -0500 Merge topic 'string_func_usage' c67ab22cdc Using front() and back() instead of calculations Acked-by: Kitware Robot Merge-request: !2571 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cf78a7df952a8d7be4228cb1c4a4b38ebc63dae8 commit cf78a7df952a8d7be4228cb1c4a4b38ebc63dae8 Merge: bb8da28 53a5aec Author: Brad King AuthorDate: Wed Nov 7 12:27:49 2018 + Commit: Kitware Robot CommitDate: Wed Nov 7 07:28:02 2018 -0500 Merge topic 'fix-double-warn-uninitialized-in-script-mode' 53a5aec899 CMP0053: Fix double warning on uninitialized variables in -P mode f92f93467e cmMakefile: Rename SuppressWatches to SuppressSideEffects Acked-by: Kitware Robot Merge-request: !2565 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bb8da283ce40d3bb06df348ea2820dd12213a2e1 commit bb8da283ce40d3bb06df348ea2820dd12213a2e1 Merge: 389002d 86c07b9 Author: Brad King AuthorDate: Wed Nov 7 12:26:54 2018 + Commit: Kitware Robot CommitDate: Wed Nov 7 07:27:27 2018 -0500 Merge topic 'genex' 86c07b9165 Help: Say early on that generator expressions can be nested. ab1d7df757 Help: add section on debugging generator expressions. e0f0f80f02 Help: Explain conversion rules of $. 2b2b41f038 Help: Code example for case-insensitive comparison e045fb202d Help: Terminate explanations with a dot. 3fa0a03b7e Help: Expand placeholders in string comparisons. fb423b3c49 Help: sort conditional expressions below string-valued ones. 867c9c9c0d Help: Add deprecation date of $ ... Acked-by: Kitware Robot Acked-by: Alex Turbov Merge-request: !2564 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=389002de96fdabd05b709415712b1d8d8aa264b9 commit 389002de96fdabd05b709415712b1d8d8aa264b9 Merge: df54255 fe40570 Author: Brad King AuthorDate: Wed Nov 7 12:26:35 2018 + Commit: Kitware Robot CommitDate: Wed Nov 7 07:26:46 2018 -0500 Merge topic 'FindSQLite3-module' fe40570608 FindSQLite3: Add module to find SQLite3 Acked-by: Kitware Robot Merge-request: !2557 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fe40570608f43aade8f4262e9ca55d98a2b169fd commit fe40570608f43aade8f4262e9ca55d98a2b169fd Author: Chuck Atkins AuthorDate: Thu Nov 1 16:48:56 2018 -0400 Commit: Brad King CommitDate: Tue Nov 6 15:05:04 2018 -0500 FindSQLite3: Add module to find SQLite3 diff --git a/Help/manual/cmake-modules.7.rst b/Help/manual/cmake-modules.7.rst index c0bef08..95744df 100644 --- a/Help/manual/cmake-modules.7.rst +++ b/Help/manual/cmake-modules.7.rst @@ -237,6 +237,7 @@ They are normally called through the
[Cmake-commits] CMake annotated tag, v3.13.0-rc3, created. v3.13.0-rc3
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 annotated tag, v3.13.0-rc3 has been created
at 3b466627c5d387c21b003d641c14685c7a6c2335 (tag)
tagging 8d70ed5a10362209d265a15d993f319235aea7e5 (commit)
replaces v3.13.0-rc2
tagged by Brad King
on Wed Nov 7 09:48:21 2018 -0500
- Log -
CMake 3.13.0-rc3
-BEGIN PGP SIGNATURE-
iQJKBAABCgA0FiEExsJlMku+vcNQtRPQLSzvEDSSFoQFAlvi+zUWHGJyYWQua2lu
Z0BraXR3YXJlLmNvbQAKCRAtLO8QNJIWhLRwEACzdUTCCWxSzWPOGEEI1va6QB8S
kp8eWut+3BgIJLnod8zwd3ui0GksxVBMRvgJ1kDX74vMQKUV/YE5JzztDUttQgHV
j+qrUzI/XM/WEDJFPfhpT2wmwfaDpXmzWfWCFNqmzobTxNgK98n06DqGTPp50oGO
nHq57FOEYevSEkc39HK3jlBY46gEad8Yja/FMgC/mwlmeYrpSCgUVWt4BwDsV8ad
aGd/ZZEgKzFsJ+BgONxznYO1q5JsmoQ5MN+hhCTxv+k26wSZlJQsOOoPag/chPqs
+Qhk+n6QnMnLC8Y5TbMr34JsazdF4iSMraeFk0jkMmg+h4PBuxiq3bT/YrJzwwBj
sfsidtLdcpyxMgtYYeOZitO8MqxHHmodySTA+wXMrMgV3nJykagAAqDp4VpF4WR0
MDuOLYE5b4aXkt49JTfsp4L0fnQiFWu964dBbPB5gcHuIEpbY5iEpiYIE9J6r3yM
W22t/pNp79Dv1Y4Rb0cMulujqsRxUrH544XWKtj/RewObRm0cRapMzd3oXt0h4Zn
r4AZRSm/CmQB7HDp8VjhdzNk8Ejv+dmA7o2F4k3mTlPNmF9877RUtv7COMExCJEG
bDvuJrQUJjxgb0qOK+zo+Wn0Y01fM4KOXPAc0Yxz3SJ6z309Te5eKvL0XmmU+tMI
G9igI8zMvASvaHYNCA==
=af+B
-END PGP SIGNATURE-
Brad King (33):
FindMPI: Pass -pthread to CUDA compiler through -Xcompiler
Merge branch 'FindMPI-pthread-cuda' into release-3.13
Merge branch 'doc-updates' into release-3.13
set_directory_properties: Restore in script mode
Merge branch 'set_directory_properties-script-mode' into release-3.13
Merge branch 'UseSWIG-multi-input' into release-3.13
Merge branch 'cuda-filter-device-link-libs' into release-3.13
Merge branch 'qccDepfile' into release-3.13
Flang: Fix command-line used to preprocess sources
Merge branch 'flang-preprocess-source' into release-3.13
Merge branch 'FindBoost-stacktrace' into release-3.13
Merge branch 'UseSWIG-typos' into release-3.13
CSharp: Fix regression in VS project type selection for custom target
Merge branch 'FindPostgreSQL-11' into release-3.13
Merge branch 'fix-custom-target-with-csharp' into release-3.13
curl: Update script to get curl 7.62.0
Merge branch 'upstream-curl' into update-curl
curl: Update build within CMake to account for 7.62 changes
FindProtobuf: Add missing link dependencies on threads
Merge branch 'FindProtobuf-threads' into release-3.13
curl: Modernize tiny test code used for build inside CMake
Merge branch 'server-file-monitor-check' into release-3.13
curl: backport upstream fix to 7.62.0 regression
add_custom_{command,target}: Fix WORKING_DIRECTORY leading genex
Merge branch 'update-curl' into release-3.13
Merge branch 'custom-command-work-dir-genex' into release-3.13
Merge branch 'blaslapack95' into release-3.13
FindBoost: Add explicit Boost_ARCHITECTURE option
Merge branch 'rename-cpack-ext-generator' into release-3.13
Merge branch 'backport-FindBoost-explicit-arch-tag' into release-3.13
Merge branch 'cpack-doc-gen-names' into release-3.13
Merge branch 'FindOpenMP-log-errors' into release-3.13
CMake 3.13.0-rc3
Craig Scott (4):
Help: Fix generators link in cpack(1) manual
Merge branch 'cpack-gen-docs-link' into release-3.13
CPack: Rename Ext generator to External
Help: Use correct CPack generator names
Curl Upstream (1):
curl 2018-10-30 (19667715)
Ivan Pozdeev (2):
FindOpenMP: Fix warnings with -Wstrict-prototypes
FindOpenMP: Log error output
Jakub Benda (2):
FindBLAS: Correct symbol searched in BLAS95 wrapper
FindLAPACK: Correct library name and symbol searched in LAPACK95 wrapper
Maikel van den Hurk (1):
QNX: Update qcc depfile flags to be compliant with ccache
Marc Chevrier (2):
Help: clarify "LINKER:" prefix usage
UseSWIG: multiple input files must be supported in version 2
Martin Quinson (1):
FindBoost: Add support for stacktrace components
Robert Maynard (1):
CUDA: Filter out non-static libraries during device linking
Sylvain Joubert (3):
UseSWIG: Typo, add missing letter
UseSWIG: Add target language and input file in command description
FindPostgreSQL: Search for version 11
Vladimir Penev (1):
server: Fix assertion failure on directory paths in file monitor
---
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits
[CMake] Why is obj.dir/depend.make.tmp not renamed to obj.dir/depend.make?
Hi, One (of really many) build trees contains a file "depend.make.tmp" and ignores dependencies leading to broken (incremental) builds. There also is a "depend.make" file in the same directory saying "Empty dependencies file. This may be replaced when dependencies are built.", so I assume the tmp file should be rename to it. The timestamp of the tmp file is newer. I like to understand the cause and how to solve it. I did not find any makefile rule that should do the rename. The problem became visible in form of a SIGSEGV of a test application. Analysing this down to the "depend.make.tmp" issue took quite a bit of time, so I like to understand the root cause and learn how to avoid it. Since only one build tree seems to be affected it seems to be a very rare issue, maybe a race condition or such. Any suggestions how I could analyse further? Steffen -- 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.13.0-rc2-398-g71db326
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 71db32660eed1f70c06b624e661f8f5c2b938907 (commit) via 8d70ed5a10362209d265a15d993f319235aea7e5 (commit) from 48de9169d0624b323462c084b68cb1fdb693d91b (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=71db32660eed1f70c06b624e661f8f5c2b938907 commit 71db32660eed1f70c06b624e661f8f5c2b938907 Merge: 48de916 8d70ed5 Author: Brad King AuthorDate: Wed Nov 7 09:48:30 2018 -0500 Commit: Brad King CommitDate: Wed Nov 7 09:48:30 2018 -0500 Merge branch 'release-3.13' --- 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.13.0-rc2-367-gdf54255
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 df542558c645f9a704fb5bcc2b2e304f6879ab35 (commit) from c46dfb213997fa9ca26bdb691a2487a85b852720 (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=df542558c645f9a704fb5bcc2b2e304f6879ab35 commit df542558c645f9a704fb5bcc2b2e304f6879ab35 Author: Kitware Robot AuthorDate: Wed Nov 7 00:01:09 2018 -0500 Commit: Kitware Robot CommitDate: Wed Nov 7 00:01:09 2018 -0500 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index 7918d80..ad29c57 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 13) -set(CMake_VERSION_PATCH 20181106) +set(CMake_VERSION_PATCH 20181107) #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
