CMake cross compiling execute custom script to flash binary into target machine - cmake

I'm running cmake on VSCode. I'm trying to set it up to invoke a custom script I wrote to flash the executable into my target mcu.
I'm reading about CROSSCOMPILING_EMULATOR, CMAKE_CROSSCOMPILING_EMULATOR and CMAKE_CROSSCOMPILING but I can't find an example of how to use them properly.
The main issue is that after the building is complete cmake is trying to run the *.elf file.
How can I flash the binary after building?

I have a script that does that and I execute it manually after each build. I want to invoke that script from cmake after building
Generally:
add_executable(the_executable_target ...)
add_custom_target(flashit
COMMAND
${YOUR_INTERPRETER_LIKE_BASH_OR_SOMTHING}
./your_script
$<TARGET_FILE:the_executable_target>
COMMENT "flashes it"
)
add_dependencies(flashit the_executable_taregt)
You could add ALL. You could also interest in add_custom_commnad(POST_BUILD ....
CMAKE_CROSSCOMPILING_EMULATOR is used for try_run, but most importantly for running tests.

Related

Building a CMake library within a Bazel project

I've written a module on top of a private fork off of TensorFlow that uses nanomsg.
For my local development server, I used cmake install to install nanomsg (to /usr/local) and accessed the header files from their installed location. The project runs fine locally.
However, I now need to package nanomsg within my TensorFlow workspace. I've tried the following two approaches, and find neither satisfactory:
Similar to this answer for OpenCV, I precompiled nanomsg into a private repository, loaded it within my workspace (within tensorflow/workspace.bzl) using an http_archive directive then included the headers and libraries in the relevant build script. This runs fine, but is not a portable solution.
A more portable solution, I created a genrule to run a specific sequence of cmake commands that can be used to build nanomsg. This approach is neater, but the genrule cannot be reused to cmake other projects. (I referred to this discussion).
Clearly cmake is not supported as a first-class citizen in Bazel builds. Is there anyone who has faced this problem in your own projects created a generic, portable way to include libraries within Bazel projects that are built using cmake? If so, how did you approach it?
As Ulf wrote, I think your suggested option 2 should work fine.
Regarding "can I identify if the cmake fails", yes: cmake should return with an error exit code (!= 0) when it fails. This in turn will cause Bazel to automatically recognize the genrule action as failed and thus fail the build. Because Bazel sets "set -e -o pipefail" before running your command (cf. https://docs.bazel.build/versions/master/be/general.html#genrule-environment), it should also work if you chain multiple cmake commands in your genrule "cmd".
If you call out to a shell script in your "cmd" attribute that then actually runs the cmake commands, make sure to put "set -e -o pipefail" in the first line of your script yourself. Otherwise the script will not fail when cmake fails.
If I misunderstood your question "Can I identify if the cmake fails", please let me know. :)
This new project: https://github.com/bazelbuild/rules_foreign_cc seems like a solution(it build rules for cmake to build your project inside bazel).

specify a custom build tool in CMake

I have a simple CMakeLists.txt
add_executable(myexecutable test.cpp)
I don't intend to use CMake to actually indirectly be responsible for building the program. I intend to use it so I can use CLion and have a nice IDE experience for working on my c++ program.
If I hit build in CLion, or cmake --build on the commandline, I want it to invoke my real buildtool. How can I specify a buildtool to run instead of the normal build cmake/clion would do? I have only been able to find add_custom_command which can be run before/after the normal cmake/clion build.
You need some fake target to let CLion understand which files are there in the project. Then you can add add_custom_target with your own build commands. So if you avoid building fake target, but instead run custom targets via run configuration by name (after CMake reload CLion will automatically create run configurations for such targets), they will call build for you.

CLion and CMake: only building a library without an executable?

How to only build a static library with clion without having an executable?
How does the CMakeLists.txt look like? (without add_executable)
Update: If I don't add executable to Clion, I have an
error, that an executable is required.
Here my CMakeLists.txt.
This is an old question. But I'll add the answer to your question as a help for other people. You need to replace your add_executable with add_library
add_library(target_name source_files)
Short answer: compile the library target and run any custom command as a placeholder to avoid the warning.
Long answer:
CLion lets you either build the whole project and run executables/configurations.
When running executables, you can choose a target to compile and the executable to run after compiling the target. For executable targets, they are usually the same thing. You compile the executable target and then run it.
It seems like this is not really designed for libraries, but there is a workaround. You usually set the target to be the library and the executable to be any executable that depends on this library. However, this is usually not very useful because if you wanted to run this executable you could just set this executable to be the target and the library would be built anyway.
So people probably want to just build the library (to check if everything is OK, etc) without compiling or running any extra executable targets. In this case, the workaround is to choose a custom executable to run after building the library, and the error message is gone.
You have nothing useful you need to run after building the library, just choose any cheap command as a placeholder. Something like "pwd" or "ls".

CMake Header Generator Updates

In CMake I currently have a simple Python script to generate a header, but if I update the script itself CMake won't re-run the script. Is there a way I can get CMake to do this?
It seems you are directly invoking your code generation script when cmake is run. While it is possible solution but it is definitely not a right way to use code generators with cmake.
I recommend you to use add_custom_command for your case:
add_custom_command(
OUTPUT generated.h
COMMAND ${PYTHON_EXECUTABLE} generator.py
DEPENDS generator.py
)
And next you can simple put your header to the list of source files passed to add_library/add_executable commands. cmake will automatically track all the dependencies and invoke your script.
Term DEPENDS generator.py informs cmake that it should regenerate header if script is changed.
With this approach file generated.h will be generated only at build time (when you run make or execute a build command in IDE). In contrast if you are running your script at cmake time (with execute_process command) then you have to rerun cmake to regenerate your file. Which is possible but you need to use some tricks to introduce a non-standard dependency.

Compile-time wildcards in cmake install targets

I'm new to cmake and I'm finding it very frustrating. I am trying to use wildcards in file paths that are evaluated when the build runs, not when the build is generated.
I have created a build that uses SWIG to generate Java wrappers for some C++ code. I can write the commands to generate the native code, compile it, and produce a working shared library, and even use the INSTALL command to install that shared library correctly. What I can't figure out how to do is to write an INSTALL command that can copy all *.java files generated by SWIG into that same install location.
It seems that cmake's FILE GLOB command does the globbing when cmake is executed, and not when the build actually runs. Of course, when cmake is executed, SWIG hasn't run yet, and the Java files don't exist.
Is there a way to do what I want? Am I going about things wrong? It seems like this is such a fundamental part of what Makefiles need to do, I'm really surprised not to find an easy way to do it.
Assuming that the Java wrappers are located in the current binary directory, you can use the following install command to copy the Java files upon install:
install(
CODE "file( GLOB _GeneratedJavaSources \"${CMAKE_CURRENT_BINARY_DIR}/*.java\" )"
CODE "file( INSTALL \${_GeneratedJavaSources} DESTINATION \"$ENV{HOME}\" )"
)
The CODE form of the install command is used to execute two CMake commands upon running the install target. The first one collects all generated Java files in a helper variable. The second one uses the INSTALL form of the file command to copy the files.
you can use install(SCRIPT swigInstaller.cmake) or install(DIRECTORY) both of which supports doing file globing at install time. You can read more about the install command at:
http://cmake.org/cmake/help/cmake-2-8-docs.html#command:install