[CMake] CPack`ing a bunch of command line tools on OS/X
Hello,
I try to pack a bunch of command line tools (and some additional data files)
into an OS/X installer. When the installer is running, it should install / copy
the command line tools and adjust the PATH variable (or what ever mean that
comes close, to make the tools available). I use a super build structure and
after build and is done, I end up with a very simple structure:
install
|
|\-bin
| |\-bjpaprog
| |\-bjpaserver
| |\-bootloader_client
| \-—create_package
|
\--firmware
|\-bootloader.tfp
|\-firmware.tfp
\-—softdevice.tfp
I use TGZ and productbuild as CPack generators. The generated zip file contains
all the files above. The generated pkg files, just starts the installer, but
does nothing.
The CMakeLists.txt for the packing looks basically like this:
cmake_minimum_required(VERSION 3.14)
set(CPACK_PACKAGE_VENDOR "Torrox GmbH & Co KG")
install(DIRECTORY ${INSTALL_DIR}/bin DESTINATION .)
install(DIRECTORY ${INSTALL_DIR}/firmware DESTINATION .)
set(CPACK_GENERATOR TGZ productbuild)
include(CPack)
I have no clue, to as where to start. Any ideas, pointers, comments?
best regards,
Torsten
signature.asc
Description: Message signed with OpenPGP
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Embedded build using ExternalProject
Hi Albrecht,
> Am 26.06.2019 um 19:10 schrieb Albrecht Schlosser :
>
> On 6/26/19 3:53 PM Torsten Robitzki wrote:
>
>> I don’t want to build any EOL test firmware, test-tools etc. just the stuff
>> that will be shipped, thus the explicit target. I can build the
>> firmware_binaries, from the source directly, without problems. But when I
>> try to build with the top-level cmake file, that contains the
>> ExternalProject_Add(), I get the usual configure output and then:
>> -- Configuring done
>> -- Generating done
>> -- Build files have been written to:
>> /Users/todi/blueswd_firmware/build/firmware_binaries-prefix/src/firmware_binaries-build
>
> Is this a on a Windows system?
No, my build host is a Mac. I figured out, what the problem with this recusion
is:
BUILD_COMMAND ${CMAKE_COMMAND} —build ${CMAKE_CURRENT_BINARY_DIR} --target
firmware_binaries
The build command really recuses into ${CMAKE_CURRENT_BINARY_DIR}, which have
to be:
BUILD_COMMAND ${CMAKE_COMMAND} —build --target firmware_packages
:-)
signature.asc
Description: Message signed with OpenPGP
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
[CMake] Embedded build using ExternalProject
Hello,
I have a project, where binaries are build for an embedded platform and for a
PC platform. To build software update packages for the embedded platforms
(files that can be used to make in the field firmware updates), tools that have
to run during the build have to be build from source first. For example
firmware.tfp have to be build by running create_package with firmware.bin.
firmware.bin have to build with settings for the embedded platform and
create_package have to be build with setting of the build host.
I’ve asked this question already a year or so ago and got the response, that
using super builds will help me. Now I try to convert the project to a super
build structure. Fortunately, there was very little content inside my main
CMakeLists.txt, mainly `add_subdirectory( source )`. Mainly, I want to build
different sets of artifacts from the same source tree, but with different
Now I’m stuck with a number of issues. First, I want to build all firmware
binaries for the NRF52 embedded platform:
ExternalProject_Add(firmware_binaries
SOURCE_DIR ${CMAKE_CURRENT_LIST_DIR}/source
INSTALL_DIR ${installDir}
CMAKE_ARGS
-DCMAKE_INSTALL_PREFIX:PATH=
-DBOOTLOADER_AES_KEY=${BOOTLOADER_AES_KEY}
-DBOOTLOADER_VERSION=${BOOTLOADER_VERSION}
-DBUILD_DEBUG=1
-DBUILD_NRF52=1
BUILD_COMMAND ${CMAKE_COMMAND} --build ${CMAKE_CURRENT_BINARY_DIR}
--target firmware_binaries
)
I don’t want to build any EOL test firmware, test-tools etc. just the stuff
that will be shipped, thus the explicit target. I can build the
firmware_binaries, from the source directly, without problems. But when I try
to build with the top-level cmake file, that contains the
ExternalProject_Add(), I get the usual configure output and then:
-- Configuring done
-- Generating done
-- Build files have been written to:
/Users/todi/blueswd_firmware/build/firmware_binaries-prefix/src/firmware_binaries-build
[ 75%] Performing build step for 'firmware_binaries'
[ 12%] Performing build step for 'firmware_binaries'
[ 12%] Performing build step for 'firmware_binaries'
[ 12%] Performing build step for ‚firmware_binaries‘
…
This line repeats until make reports:
make[776]: /usr/local/Cellar/cmake/3.14.3/bin/cmake: Resource temporarily
unavailable
make[776]: *** wait: No child processes. Stop.
make[776]: *** Waiting for unfinished jobs
make[776]: *** wait: No child processes. Stop.
Any idea, what might be wrong here? Some kind of recursion?
An other issue: I want to forward targets to the super build, so that I can
build them there. For example I have ~30 unit test programs and when I’m
working in a certain area, I usually want to build exactly one of this
programs. Is it possible to export them as targets of the super build?
A third issue that I have is, that changes to the CMakeLists.txt files in the
Project are not reflected by the super build. If I make a change to one of the
CMake files under ${CMAKE_CURRENT_LIST_DIR}/source, I usually have to delete
the whole build folder and start from scratch with the build. Is there an other
way to force the super build to recognize the changes? (Note:
${CMAKE_CURRENT_LIST_DIR}/source is not added as subdirectory to the top level
(super build) CMakeLists.txt).
best regards,
Torsten
P.S.:
$ cmake --version
cmake version 3.14.3
signature.asc
Description: Message signed with OpenPGP
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] Properly Documenting a CMake Module
> Am 13.02.2019 um 13:42 schrieb Brad King via cmake-developers > : > > The online docs, like those at https://cmake.org/cmake/help/v3.14 > do publish a `/objects.inv` to support intersphinx: > > http://www.sphinx-doc.org/en/master/usage/extensions/intersphinx.html > > This was done on request of some users so I haven't looked into how > that works, but one should be able to use sphinx to generate one's > own documentation and still cross-reference CMake’s online docs. I can confirm that this works as expected. Used it by myself. signature.asc Description: Message signed with OpenPGP -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake-developers
Re: [CMake] Syntax to document cmake files, functions and macros
> Am 31.01.2019 um 19:55 schrieb Marc Herbert : > > So is there a relatively simple way to run the same tooling on any regular, > non-module .cmake files > too and produce project-specific documentation? We are working on a larger CMake project and we use Sphinx. We use sphinxcontrib.moderncmakedomain as extension, which adds CMake syntax highlighting and sphinx.ext.intersphinx to allow us, to refer to the original CMake documentation. regards, Torsten signature.asc Description: Message signed with OpenPGP -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
[CMake] Checking Variables in a tool-chain file
Hi,
I have a tool-chain file, which requires a variable to be set to the path to
the compiler on the local machine:
set(CMAKE_C_COMPILER ${ARM_GCC_TOOL_PATH}/bin/arm-none-eabi-gcc)
set(CMAKE_CXX_COMPILER ${ARM_GCC_TOOL_PATH}/bin/arm-none-eabi-g++)
Now I want to give the user an error message, in case that this variable is not
set. The „usual“ check for the existence of the variable doesn’t work, because
the tool-chain file is included in different context, without access to the
cache.
Any idea?
regards,
Torsten
signature.asc
Description: Message signed with OpenPGP
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
[CMake] add_executable() with BYPRODUCT
Hello, we have some applications for something similar to BYPRODUCTS in add_custom_command() when it comes to add_exectuable(). For example, we want to do some resource calculation based on map files. And in a perfect world, the map file would be a BYPRODUCT of the executable and we could make the resource calculation dependent on the map file. Thus a missing map file would result in a relinking of the executable. Is it possible to define a BYPRODUCT of an executable, somehow? Kind regards, Torsten signature.asc Description: Message signed with OpenPGP -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
[CMake] Integrating Build Date/Time into Binary
Hello, we are porting a larger set of projects (~70) to CMake. The current build has a feature to integrate the current timestamp of the build into the final binary / target. If a target is relinked, a header (id.h) is created with the current timestamp, a user provided C file (id.c), including that header is recompiled and linked into the target as well. While thinking about how to provide a similar solutions, we came up with some ideas: 1) add_custom_command() The projects have to move id.c into a separate library. For the main target, all depending targets (excluding the library containing id.c) are determined. A add_custom_command() creates id.h and depends on the list of determined, depending targets. The drawback that I see here, is that other, additional dependencies (like introduced with add_custom_command()) are not taken into account and that we have to recreate the algorithm to determine all direct and indirect depending targets. 2) add_custom_command(TARGET PRE_LINK…) The generation of both, id.h and id.c are excluded from the main target and are build by the add_custom_command(). The resulting object file is added as GENERATED, EXTERNAL_OBJECT source file to the main target. The drawback here is, that the custom command have to compile the id.c file, using the right compiler, the right flags, include paths etc. To me it doesn’t sound to be a very special requirement to have some kind of hash (timestamp in this case) over the compiled files in the resulting binary. How do others solve this or similar problems? Any comments to our ideas? TIA, Torsten signature.asc Description: Message signed with OpenPGP -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
[cmake-developers] Support for list length expression in if()-command?
Hi, I have a customer that requires quite often to check, whether a list contains at least a given number of elements. As we do not have functions with return values, this requires him to inquire the length of a list before taking special actions. To simplify that task (and without larger changes in CMake [like introducing *real* functions]), he came up with the idea to extend the if()-command with a LENGTH operator: set(list) … if (LENGTH list GREATER 1) … endif() Would such an extension be accepted as pull request, if we would provide it? regards, Torsten signature.asc Description: Message signed with OpenPGP -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake-developers
[CMake] Escaping end of line anker in regex
Hi, I’ve stumbled over following issue: if (NOT ^ MATCHES ^\^ ) message(FATAL_ERROR "Anker not found!") endif() if (NOT $ signature.asc Description: Message signed with OpenPGP -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] Idea for Multi-Toolchain Support
Hi, > Am 17.12.2018 um 21:18 schrieb Kyle Edwards via cmake-developers > : > > 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) 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. best regards, Torsten signature.asc Description: Message signed with OpenPGP -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake-developers
[cmake-developers] Test for list size
Hi, we have often the need to test for a minimum list size list(LENGTH list list_size) if (list_size GREATER 1) … This happens so much, that we though it might be helpful to extend the if-syntax to allow this to be written in a more compact way. For example: if (LENGTH list GREATER 1) … Or maybe by introducing functions that can return values (length being a „function“ here): if (length[list] GREATER 1) … What do you think? Are we the only ones that could make good use out of this extension? best regards, Torsten signature.asc Description: Message signed with OpenPGP -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake-developers
[CMake] extending clean for Ninja
Hi, we have some source file generators, that take a known list of input files and generate an „relatively“ unknown list of output files. The exact list of output files depend on the content of the input files. The „usual“ way to solve this seams to have an add_custom_target() call, and listing all output files as BYPRODUCTS, because then Ninja would know the output files as being targets and would delete them when asked to clean the project. Assumed all output files would be in the same directory and that it would be safe to delete the entire directory, I though, I could add the directory name as BYPRODUCTS. Unfortunately this hack doesn’t work, because the OS function that Ninja uses to remove files does not delete not empty directories. If I could use the very same generator to produce the list of output files, I could then add this list as BYPRODUCTS option to `add_custom_target()`. One problem still would remain: if I change one of the input files, so that the list of output files change, cmake would have to re-run. Does someone of you have an idea, how to force cmake to re-run, if a certain list of files changed? Is there an easier way to archive what I want (to delete the output files when Ninja -t clean is called)? Best regards, Torsten signature.asc Description: Message signed with OpenPGP -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] [CMake] dependencies of cross compiliations
> Am 27.11.2018 um 19:55 schrieb Eric Noulard : > > However from my point of view and my cross-compiling experience when you > cross-compile you have: > > 1) the host compiler which is used to compile "host tools" > 2) the target compiler (may be several of them) to "cross-compile" > > My assumption are: > a) when you cross-compile your build is a "whole" and you shouldn't have to > setup some superbuild >structure for building host tools ht_exe and another for target1 tool > t1t_exe and another one for target2 tool t2t_exe. > > b) what you want is to build: > ht_exe for the host > possibly use ht_exe during the build to generate some [source] file > t1t_exe for the [cross]target1 > t2t_exe for the [cross]target2 > > c) you seldomly compile the same source for the host AND the target, but it > may happen. In case, you are doing unit tests, it’s normal to have the same code running in a test on the host platform and in the final binary on the target. I think, having more than 1 target platform becomes more and more normal as it becomes more usual to have multiple microcontrollers in a project. Previously, I have encoded this in the build type. So instead of just having Debug and Release, I had HOST_Debug, HOST_Release NRF51_Debug, NRF51_Release, STM8_Debug, STM8_Release and so on. It doesn’t annoy me very much, that I have to run CMake 3 times to get all the binaries for a release build. The problem that I have, are dependencies between this builds. If I write a tool that (for example) generates source files for one of the target platforms, the build for the host platform must run before the build for that target platform. And when I make changes to that tool, I want the build to regenerate the generated source files. Keeping track of this dependencies to solve this kind of ordering issues and to allow minimum rebuilds, is the main purpose of any build system. To solve this with CMake, I think we need a way to define the dependencies between build types (in the example above, from the generator from the host build to the generated source file in one of the target builds) and CMake needs to know the build directory for all build types (not only the current). > The wish-season is coming up, so that's sort of what I would like to > have. Now it's your turn. No bikeshedding please, only deliveries ;) How about ``add_dependencies()`` allowing me to define dependencies between different build types? :-) best regards, Torsten signature.asc Description: Message signed with OpenPGP -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake-developers
Re: [CMake] dependencies of cross compiliations
> Am 27.11.2018 um 19:55 schrieb Eric Noulard : > > However from my point of view and my cross-compiling experience when you > cross-compile you have: > > 1) the host compiler which is used to compile "host tools" > 2) the target compiler (may be several of them) to "cross-compile" > > My assumption are: > a) when you cross-compile your build is a "whole" and you shouldn't have to > setup some superbuild >structure for building host tools ht_exe and another for target1 tool > t1t_exe and another one for target2 tool t2t_exe. > > b) what you want is to build: > ht_exe for the host > possibly use ht_exe during the build to generate some [source] file > t1t_exe for the [cross]target1 > t2t_exe for the [cross]target2 > > c) you seldomly compile the same source for the host AND the target, but it > may happen. In case, you are doing unit tests, it’s normal to have the same code running in a test on the host platform and in the final binary on the target. I think, having more than 1 target platform becomes more and more normal as it becomes more usual to have multiple microcontrollers in a project. Previously, I have encoded this in the build type. So instead of just having Debug and Release, I had HOST_Debug, HOST_Release NRF51_Debug, NRF51_Release, STM8_Debug, STM8_Release and so on. It doesn’t annoy me very much, that I have to run CMake 3 times to get all the binaries for a release build. The problem that I have, are dependencies between this builds. If I write a tool that (for example) generates source files for one of the target platforms, the build for the host platform must run before the build for that target platform. And when I make changes to that tool, I want the build to regenerate the generated source files. Keeping track of this dependencies to solve this kind of ordering issues and to allow minimum rebuilds, is the main purpose of any build system. To solve this with CMake, I think we need a way to define the dependencies between build types (in the example above, from the generator from the host build to the generated source file in one of the target builds) and CMake needs to know the build directory for all build types (not only the current). > The wish-season is coming up, so that's sort of what I would like to > have. Now it's your turn. No bikeshedding please, only deliveries ;) How about ``add_dependencies()`` allowing me to define dependencies between different build types? :-) best regards, Torsten signature.asc Description: Message signed with OpenPGP -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] How is ARGN passed to a macro
Hi Andreas,
> Am 21.11.2018 um 20:18 schrieb Andreas Naumann :
>
> I think the behavior is explained in [1] and [2]. In particular the second
> section of [2] states that the parameter " [...] such as ARGN are not
> variables in the usual CMake sense. They are string replacements [...]". And
> the example at the end of [2] seems to match your test perfectly.
yes, but what puzzles me, is that I can’t print ${ARGN} in the macro (but in
the function) but I can loop over it. That seems to be somehow strange to me.
Anyhow, thanks a lot and as long as this behavior is defined and (most likely)
stays this way, I can work with it :-)
regards,
Torsten
signature.asc
Description: Message signed with OpenPGP
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
[CMake] How is ARGN passed to a macro
Hi,
I’ve stumbled over following behavior and now I’m searching for the rules, that
explains that behavior:
test.cmake:
macro(check_argn)
message("in macro check_argn ARGN: ${ARGN}")
if(ARGN)
foreach(item IN LISTS ARGN)
message("ARG: ${item}")
endforeach(item)
message("ARGN: ${ARGN}")
endif()
endmacro()
function(f1 a)
message("in function ARGN: ${ARGN}")
check_argn()
endfunction()
f1(1)
f1(1 2)
This will yield the following output:
$ cmake -P ./test.cmake
in function ARGN:
in macro check_argn ARGN:
in function ARGN: 2
in macro check_argn ARGN:
ARG: 2
ARGN:
I would expect ARGN to behave exactly the same in the macro, as in the
function, but apparently there is a difference. Can someone of you explain that
to me?
TIA and kind regards,
Torsten
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Re: [CMake] dependencies of cross compiliations
> Am 09.11.2018 um 15:55 schrieb Miller Henry : > > There are two options. Each with pros and cons. > > The first what you are doing now, except you use external project > https://cmake.org/cmake/help/v3.12/module/ExternalProject.html to build the > host tools instead of add_custom_command. It otherwise has all the cons you > mention, but are they significant (this is a question that is different for > each project)? Going back to the manual build for host before the target > isn’t bad, though it is harder to teach. I think for the example use case, this will work best. Especially, if there are source files (for example constants) are shared among both platforms. Thanks, Torsten -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
[CMake] dependencies of cross compiliations
Hi, I hope this question was not asked before. I work in the embedded field and there it is usually to have at least two different build platforms. The Host platform, where unit tests are build (and where CMake is running) and an embedded Target platform, where targets are build with a cross compiler. Sometimes such a system comes with self-written tools that are build and run on the Host platform to build a target for the embedded Target platform (adding meta data to a binary to be used by a bootloader for example). Usually I have two different build folders, one for the Host platform and one for the Target platform, using different calls to cmake to choose from a set of tools and targets. But when using this approach, it is necessary that the Host platform build ran before the Target platform build, so that tools that are required for the Target platform are build during the Host target build. One solution I’ve came up with, is to build the required tools during the Target platform build, using an add_custom_target() to invoke the Target compiler directly. This works fine, as long as the tools are basically build just out of a couple of files. What would be the „CMake-Way“ to add the tools (that have to be build on the Target platform) as dependency to targets that have to be build for the Target (cross compile) platform? Kind regards and thanks in advance, Torsten -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
