Re: [cmake-developers] Possible Bug With "add_custom_command()" and the Visual Studio Generator for CMake
Ha that actually seems like a totally separate bug.
>From what I understand - if "add_custom_command()" is not associated with
any target and is just given a command it is supposed to run at build time
every time the build is initiated, but with the Visual Studio generator it
seems to just skip over it unless CMake has something else it needs to do.
On Fri, Feb 8, 2019 at 8:44 PM frodak17 wrote:
> I haven't tried it out but I'm not exactly surprised it wouldn't work with
> Visual Studio 2017.
>
> It seems to be similar to the issue mentioned here:
> https://stackoverflow.com/q/54557801/1028434
>
> The problem I noticed in the case of the StackOverflow question,
> "add_custom_target(testcmake2 ALL)" doesn't have a "command" so it doesn't
> generate an output.
>
> When performing a build Visual Studio prints a message like "all outputs
> up to date" and skips over it. So any associated custom commands with the
> target are never run.
> Adding a "command" that is even an echo, like add_custom_target(testcmake1
> COMMAND ${CMAKE_COMMAND} -E echo "Running testcmake1 step 1"), and the
> problem goes away.
>
>
>
> On Fri, Feb 8, 2019 at 6:08 PM Timothy Wrona
> wrote:
>
>> I have been following the examples in the "CMake Cookbook" by Radovan
>> Bast and Roberto Di Remigio and came across one example that doesn't appear
>> to work right on Windows.
>>
>> The source code for these example can be found here:
>> https://github.com/dev-cafe/cmake-cookbook
>>
>> Chapter-06/Recipe-07 is supposed to update the Git commit hash referenced
>> by the version header file every time the project is built. According to
>> the book, "add_custom_command()" is supposed to execute on every build
>> regardless of whether any files are changed. This example seems to work
>> correctly in a Linux environment, but not in Windows with the Visual Studio
>> Generator. When a new commit is created (an empty commit created with "git
>> commit --allow-empty") the custom command is never called and the commit
>> hash is not updated correctly.
>>
>> For specific instructions to reproduce the issue, see this bug report I
>> opened for the example in the book:
>> https://github.com/dev-cafe/cmake-cookbook/issues/506
>>
>> I assumed this was an issue with the example, but it looks like the
>> Visual Studio Generator may not be handling "add_custom_command()"
>> correctly and may be the source of the problem.
>>
>> System info:
>> CMake version 3.13.3
>> Windows 10
>> Visual Studio 2017
>> --
>>
>> 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
>>
>
--
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] Possible Bug With "add_custom_command()" and the Visual Studio Generator for CMake
I haven't tried it out but I'm not exactly surprised it wouldn't work with
Visual Studio 2017.
It seems to be similar to the issue mentioned here:
https://stackoverflow.com/q/54557801/1028434
The problem I noticed in the case of the StackOverflow question,
"add_custom_target(testcmake2 ALL)" doesn't have a "command" so it doesn't
generate an output.
When performing a build Visual Studio prints a message like "all outputs up
to date" and skips over it. So any associated custom commands with the
target are never run.
Adding a "command" that is even an echo, like add_custom_target(testcmake1
COMMAND ${CMAKE_COMMAND} -E echo "Running testcmake1 step 1"), and the
problem goes away.
On Fri, Feb 8, 2019 at 6:08 PM Timothy Wrona wrote:
> I have been following the examples in the "CMake Cookbook" by Radovan Bast
> and Roberto Di Remigio and came across one example that doesn't appear to
> work right on Windows.
>
> The source code for these example can be found here:
> https://github.com/dev-cafe/cmake-cookbook
>
> Chapter-06/Recipe-07 is supposed to update the Git commit hash referenced
> by the version header file every time the project is built. According to
> the book, "add_custom_command()" is supposed to execute on every build
> regardless of whether any files are changed. This example seems to work
> correctly in a Linux environment, but not in Windows with the Visual Studio
> Generator. When a new commit is created (an empty commit created with "git
> commit --allow-empty") the custom command is never called and the commit
> hash is not updated correctly.
>
> For specific instructions to reproduce the issue, see this bug report I
> opened for the example in the book:
> https://github.com/dev-cafe/cmake-cookbook/issues/506
>
> I assumed this was an issue with the example, but it looks like the Visual
> Studio Generator may not be handling "add_custom_command()" correctly and
> may be the source of the problem.
>
> System info:
> CMake version 3.13.3
> Windows 10
> Visual Studio 2017
> --
>
> 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
>
--
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
[cmake-developers] How does CMake know when to use the rpath option in the build tree with a combination of static internal and shared external libraries?
By running "readelf -d " I have recently become aware that the Debian Buster linker automatically turns all rpath requests into runpath, and that runpath versus rpath difference apparently creates some issues I am trying to debug for the PLplot OCaml binding that did not appear for my previous (Debian Jessie) platform. (Note, that our ocaml binding implements its language support in a primitive way using add_custom_command and add_custom_target because as far as I know there is no OCaml language support in upstream CMake.) These runpath issues only show up for the PLplot build-tree configuration that links all PLplot components statically, but note that external libraries (such as libLASi, see below) are still linked as shared for this case. CMake does the right thing in the build tree for the corresponding C example (with obviously good CMake language support for C) so I need some help in figuring out what goes on there so that I can also do the right thing for OCaml. (Note for the PLplot static build, the PLplot libraries and C executables are all built using the PUBLIC signature of target_link_libraries to force transitive linking in this (static) case.) The reason I have to be concerned about runpath is one of those external libraries (libLASi) is locally built and installed in a non-standard location so we have this situation for it: software@merlin> readelf -d /home/software/lasi_svn/install/lib/libLASi.so |grep -Ei 'needed|path' 0x0001 (NEEDED) Shared library: [libpangoft2-1.0.so.0] 0x0001 (NEEDED) Shared library: [libfontconfig.so.1] 0x0001 (NEEDED) Shared library: [libpango-1.0.so.0] 0x0001 (NEEDED) Shared library: [libgobject-2.0.so.0] 0x0001 (NEEDED) Shared library: [libglib-2.0.so.0] 0x0001 (NEEDED) Shared library: [libfreetype.so.6] 0x0001 (NEEDED) Shared library: [libstdc++.so.6] 0x0001 (NEEDED) Shared library: [libm.so.6] 0x0001 (NEEDED) Shared library: [libgcc_s.so.1] 0x0001 (NEEDED) Shared library: [libc.so.6] 0x001d (RUNPATH)Library runpath: [/home/software/lasi_svn/install/lib] In a PLplot C example, the result of a build that was completely automated by CMake (with no mention of rpath in our build system for this PLplot static library case) is as follows: software@merlin> readelf -d examples/c/x01c |grep -Ei 'needed|path' 0x0001 (NEEDED) Shared library: [libLASi.so.2] 0x0001 (NEEDED) Shared library: [libpangoft2-1.0.so.0] 0x0001 (NEEDED) Shared library: [libpango-1.0.so.0] 0x0001 (NEEDED) Shared library: [libgobject-2.0.so.0] 0x0001 (NEEDED) Shared library: [libglib-2.0.so.0] 0x0001 (NEEDED) Shared library: [libfontconfig.so.1] 0x0001 (NEEDED) Shared library: [libfreetype.so.6] 0x0001 (NEEDED) Shared library: [libshp.so.2] 0x0001 (NEEDED) Shared library: [libqhull.so.7] 0x0001 (NEEDED) Shared library: [libm.so.6] 0x0001 (NEEDED) Shared library: [libstdc++.so.6] 0x0001 (NEEDED) Shared library: [libgcc_s.so.1] 0x0001 (NEEDED) Shared library: [libc.so.6] 0x001d (RUNPATH)Library runpath: [/home/software/lasi_svn/install/lib] And the reason for that RUNPATH line was the combination of CMake building this example using the option -Wl,-rpath,/home/software/lasi_svn/install/lib and Debian Testing transmuting that rpath request to runpath. So all is well with that C example, but I would like to know *how* CMake knew (for the build tree case) that the rpath option was needed. That information is not available for any of the PLplot static libraries in this case, and I also cannot find any mention of rpath in our build system logic for this static case. So assuming I haven't missed something in the PLplot build system, I am pretty sure that CMake automatically detected that libLASi itself had RUNPATH set, but if that is true, how did it detect that? For example, does CMake use something like "readelf -d |grep -i path" for all dependent shared libraries to figure this out, or is there an easier way? Once I get that information, then I will attempt to do something similar for the corresponding OCaml example(s) where the current readelf result is software@merlin> readelf -d examples/ocaml/x01ocaml |grep -Ei 'needed|path' 0x0001 (NEEDED) Shared library: [libLASi.so.2] 0x0001 (NEEDED) Shared library: [libpangoft2-1.0.so.0] 0x0001 (NEEDED) Shared library: [libpango-1.0.so.0] 0x0001
[cmake-developers] Possible Bug With "add_custom_command()" and the Visual Studio Generator for CMake
I have been following the examples in the "CMake Cookbook" by Radovan Bast and Roberto Di Remigio and came across one example that doesn't appear to work right on Windows. The source code for these example can be found here: https://github.com/dev-cafe/cmake-cookbook Chapter-06/Recipe-07 is supposed to update the Git commit hash referenced by the version header file every time the project is built. According to the book, "add_custom_command()" is supposed to execute on every build regardless of whether any files are changed. This example seems to work correctly in a Linux environment, but not in Windows with the Visual Studio Generator. When a new commit is created (an empty commit created with "git commit --allow-empty") the custom command is never called and the commit hash is not updated correctly. For specific instructions to reproduce the issue, see this bug report I opened for the example in the book: https://github.com/dev-cafe/cmake-cookbook/issues/506 I assumed this was an issue with the example, but it looks like the Visual Studio Generator may not be handling "add_custom_command()" correctly and may be the source of the problem. System info: CMake version 3.13.3 Windows 10 Visual Studio 2017 -- 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
