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
Re: [cmake-developers] CMake GUI "Stop" button does not halt exec_process
On Wed, Jan 16, 2019 at 3:27 PM Venedict Tchistopolskii wrote: > Pressing "STOP" in the CMake GUI interface halts CMake itself but does not > stop any execute_process that is going on at the time. This makes it hang > until the process finishes, since no interrupt is sent.. > > Aggravating when you're using an exterior script (e.g. a .exe or .py) that > e.g. handles package maintenance. Would hang up for the entire duration of > ~40 minutes unless you force kill that sub process. > > I think force-killing CMake GUI also won't forward the kill to the > exec_process, orphaning it.>.< > > My reproduction: > Windows 10 > CMake script via CMakeLists.txt files > Executing a Python script PyInstalled into a .exe for windows use -> > Downloads and untars some SDK's and shows progress (plus a bit more) but > takes 40-70 minutes average. > > Canceling CMake won't cancel python script -> 70min hangup or requirement > to use task manage and force-kill subprocess. > > Let me know any suggestions or possible fixes > -- > > I commented on this about a month ago: > Looks like this would require a code change how the GUI works and the > internal way execute_process works. Now execute_process knows how to > cancel a process due to time out, but it didn't seem to check for anything > else. Essentially it looks like execute_process needs to be signaled by > the button press to cancel the process in addition to checking for > timeout. There are other internal interrupt flags that seem to be set when > the GUI stop button is pressed. Anyways this is what I noticed in the > code base. > So in the execute_process function it sits in a loop waiting for the process to finish. If the timeout occurs it kills the process. At the same time when the GUI stop button is pressed it sets some sort of abort flag that is used during command processing to quit processing commands. It seems that someone should be able to take this abort flag and use it to not only stop the command processing loop but to also have the execute_process timeout loop to kill the process if the abort flag is set. Best regards, F -- 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] Idea for Multi-Toolchain Support
On Sat, Dec 22, 2018 at 10:58 AM Torsten Robitzki wrote: > Hi, > > > Am 17.12.2018 um 21:18 schrieb Kyle Edwards via cmake-developers < > cmake-developers@cmake.org>: > > > > Then, executables and libraries could have a toolchain specified: > > > > add_executable(BuildUtility TOOLCHAIN DEFAULT ...) > > add_library(MyLibrary TOOLCHAIN CrossToolchain …) > > or even toolchains: > > add_library(feature1 TOOLCHAINS CrossToolChain HostToolChain) > > add_executable(Firmware TOOLCHAIN CrossToolChain) > target_link_libraries(Firmware feature1) > > add_executable(Test_Feature1 TOOLCHAIN HostToolChain) > target_link_libraries(Test_Feature1 feature1) > > A nice feature would be to let toolchain propagate along the dependency > graph defined by `target_link_libraries`. So in the example above, the > TOOLCHAINS option to `add_library` would be optional, because the target > Firmware requires feature1 to be build with CrossToolChain and > Test_Feature1 to be build with HostToolChain. Which requires the build to > have different binary directories for every toolchain. (Which for me is an > indication that having multidimensional build types would be the more > natural way to go) > > How would different binary directories for every toolchain work? CMAKE_CURRENT_BINARY_DIR wouldn't even be accurate let alone all of the code that tracks these things. Using target_compile_options() and file level compile options would have to use generator expressions to pass the correct flags to the correct toolchain. If TOOLCHAINS is specified and the CMakeLists.txt file only contains the library target then nothing is built because there is nothing linking against it? Offhand it seems to me that adding multiple binary directories based on which toolchain was used is a larger change to the infrastructure then adapting a generator to use multiple toolchains in its output. > What I’m still missing is support to define dependencies between different > targets (build by different toolchains), so that I can describe that I > require a tool that is build with the HostToolChain, to generate a file > that is required by the part of the build, that is using the > CrossToolChain. And, of cause, if the source of that tool changes, that > tool have to be rebuild and the generated file from the CrossToolChain part > of the build have to be rebuild. > > All the commands already support this. add_executable() rebuilds the host tool if the source file change for the tool is updated. add_custom_command() runs whenever any target specified in DEPENDS is rebuilt. So in this case you specify the custom command to run the host tool and generate the output and set DEPENDS to host tool target. If the host tool is updated due to a source file change then the tool is rebuilt and the file is regenerated. The cross toolchain target that uses the generated file rebuilds because the timestamp on generated file was updated. -- 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] Idea for Multi-Toolchain Support
On Tue, Dec 18, 2018 at 4:41 PM Kyle Edwards wrote: > On Tue, 2018-12-18 at 16:12 -0500, frodak17 wrote: > > What about conflicting build types when building a host tool target vs the > cross compiler target? > For instance the host tool may (should?) be built as a release project > (default optimization levels) but the cross compiler project could be built > as a debug project (so you can debug it with no optimizations)? > I guess it would then be CMAKE__BUILD_TYPE and then targets > using that toolchain would be built with that build type. > > > I think that both host and cross targets would be built with the same > build type. If you're using a multi-config generator like VS or Xcode, how > do you specify which combination of configs you want? It's simpler if every > target is built as the same type, whether it's host or cross. Think about > it - the current system already expects that every target in the project is > built as the same build type. There's no way to specify "foo is built as > debug, bar is built as release." Why would this assumption change just > because we add a multi-toolchain mechanic? > I have thought about it which is why I asked. The original assumption of one toolchain per CMake project is being extended. So why not think of extending the build type. Sure it's simpler to ignore the build type. However, it doesn't make sense to me to build and run a host tool in debug mode when it could be running faster if built in release mode. This is independent of whatever I'm doing with cross-compiler targets. You're already updating the generator to pick and choose the proper flags just on the tool chain type and it already picks the correct flags based on the configuration type. But instead of the generator looking at the global build type it looks at the target build type. The target build type could default to the global build type and be overridden via a property. Multi config generators would be problematic if they don't have a Configuration Manager that allows for setting different projects with different configurations (like Visual Studio) but is that reason enough to exclude the idea for single configuration generators? > On the other hand this doesn't really help anyone working with mixed build > systems. What you can't do in a straight forward manner is host tool > development with Visual Studio or Eclipse, execute it and use it's results > with a cross compiler (that uses Ninja or Makefiles) targeting an embedded > system. > > > Every target would be built by the same generator regardless of whether > it's a host or cross target. So if you select the VS generator, both the > host tools and the embedded software would be built in VS (if this is > possible.) Likewise for Ninja and Make. > > In this case I think that what you want is to easily control multiple > projects using different build systems, the inter-dependencies, and easily > specify that external project A produces a file for external project B. > Ideally you would be in the root of the build folder and type 'cmake > --build .' and have it take care of everything with minimal extraneous > build tool executions or sometimes even invoking the build tool in parallel > for external projects that don't depend on each other. > > > If you want to build different parts of the software with different > generators (build systems) then you're better off using a superbuild with > ExternalProject. The intent of this proposal is to allow users to build > both host tools and cross-compiled software in the same build tree with the > same generator. > Sure. I was thinking / commenting about the other real world projects that are more complicated. Can add_custom_command() be used to run a binary that was built as an ExternalProject which it was linked via depends to generate a file that is used by several other ExternalProjects and it's all glued together with proper dependencies so it can be invoked by a single command? If this can already be simply done why is anyone asking to use multiple toolchains in a single project? You just use an ExternalProject with each toolchain file and you're done, or is this a shortcut method instead of using ExternalProject to build the host tool? If ExternalProject doesn't define a target that can be used as a dependency for add_custom_command() or add_dependencies() then isn't this a problem which is driving people to ask to use multiple toolchains? https://cmake.org/pipermail/cmake-developers/2018-December/030920.html This email seems to indicate that ExternalProject can't be used with add_custom_command(). -- 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 offeri
Re: [cmake-developers] Idea for Multi-Toolchain Support
> How does this work with multiple languages and the project() command and >> enable_language() commands? >> > Both project() and enable_language() could be extended with an optional > TOOLCHAIN argument. > So it would be something like project( [TOOLCHAIN [LANGUAGES] [...]) where TOOLCHAIN and its supported languages can be repeated for each tool chain. i.e project(whatever TOOLCHAIN default LANGUAGES cpp TOOLCHAIN cross LANGUAGES c) For instance you want to use the host c++ compiler and a toolchain > specified compiler for c and c++. > When project() enables the c++ compiler it runs through a bunch of scripts > to find and test the compiler also setting several CMAKE__* variables > to use that compiler. These variables also happen to be the default > compile options for the build types when using that compiler. > > > The point of this idea is to get rid of the old variable-based system and > have everything instead be a property of a toolchain. So the scripts would > set properties of the default toolchain instead of setting variables. > > Then the same thing happens with the tool-chain specified compiler for > these languages how do you track that the variables are different for these > two toolchains? > Are these variables now project scoped and for any given project it is > limited to one toolchain per language per project? > > > See above. > But isn't this all (or mostly) cached so you don't have to redo all this when regenerating build files. I guess it would be CMAKE___* ? What about conflicting build types when building a host tool target vs the cross compiler target? For instance the host tool may (should?) be built as a release project (default optimization levels) but the cross compiler project could be built as a debug project (so you can debug it with no optimizations)? I guess it would then be CMAKE__BUILD_TYPE and then targets using that toolchain would be built with that build type. On the other hand this doesn't really help anyone working with mixed build systems. What you can't do in a straight forward manner is host tool development with Visual Studio or Eclipse, execute it and use it's results with a cross compiler (that uses Ninja or Makefiles) targeting an embedded system. In this case I think that what you want is to easily control multiple projects using different build systems, the inter-dependencies, and easily specify that external project A produces a file for external project B. Ideally you would be in the root of the build folder and type 'cmake --build .' and have it take care of everything with minimal extraneous build tool executions or sometimes even invoking the build tool in parallel for external projects that don't depend on each other. -- 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] Idea for Multi-Toolchain Support
How does this work with multiple languages and the project() command and enable_language() commands? For instance you want to use the host c++ compiler and a toolchain specified compiler for c and c++. When project() enables the c++ compiler it runs through a bunch of scripts to find and test the compiler also setting several CMAKE__* variables to use that compiler. These variables also happen to be the default compile options for the build types when using that compiler. Then the same thing happens with the tool-chain specified compiler for these languages how do you track that the variables are different for these two toolchains? Are these variables now project scoped and for any given project it is limited to one toolchain per language per project? -- 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] Idea for Multi-Toolchain Support
What first cross my mind with '"utilities" needed for build' is when you have to build the cross-compiler in the first place before you build anything for the target. If so how do you handle verification of the tool-chain can build a working executable or library? Normally that is done at the time before project files are generated but it has to either be skipped or delayed because the toolchain doesn't even exist because it has to be built first by the host tools. For tool-chains that already exist on the host machine then add_toolchain() command is when you can test and verify its functionality? So if you want to build both for host and cross toolchain you'll have to >> explicitely >> add_executable/library(MyLibrary TOOLCHAIN DEFAULT) >> add_executable/library(MyLibrary TOOLCHAIN CrossToolchain) >> > Do these targets automatically get separate binary directories so that the outputs don't overwrite each other? I assume this feature is limited only to ninja or makefile generators? -- 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
