[CMake] (no subject)
I'm running into somewhat of an arcane problem at the moment. The setup: * I have a source file that is autogenerated. In this case it is event_log_msg_if.ac.cpp. * I have marked the cpp as autogenerated via the 'set_source_files_properties' api * I have an add_library(foo /path/to/file/event_log_msg_if.ac.cpp) Any idea why I'm getting an No rule to make target for this? It looks like cmake doesn't have a rule to build .cpp files. Could the .ac.cpp cause an issue? Excerpt of output: Scanning dependencies of target event_log [ 65%] Building CXX object event_log/CMakeFiles/event_log.dir/local/ac/event_log_msg_if.ac.cpp.o make[2]: *** No rule to make target `../event_log/event_log/local/ac/event_log_msg_if.ac.cpp', needed by `event_log/CMakeFiles/event_log.dir/event_log/local/ac/event_log_msg_if.ac.cpp.o'. Stop. make[1]: *** [event_log/CMakeFiles/event_log.dir/all] Error 2 Thomas Taranowski | 425-442-9209 | skype: thomas.taranowski | baringforge.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: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Question about best practices for large Multi-stage builds
I have the following build structure: workspace/ CMakeLists.txt # top level cmake component_a/ CMakeLists.txt # component cmake src/ # source in here component_b/ CMakeLists.txt # component cmake src/ # source in here Now, I'm trying to implement a multi-stage build which does the following: 1) builds some external third-party dependencies. 2) auto-generate some code 3) build the source 4) package the result To do this, I'd like to implement some top level build targets in cmake, so I can run make auto_generate, make third_party, etc. I can see a couple different potential ways to do this, but I've not been able to google up documentation that discusses the best method for implementing this. How are folks generally approaching this top level build target issue? Do you have a top level add_custom_target that then calls each subdirectories custom target of the same name, or is there some cmake feature that supports this that I have not yet discovered? Thomas Taranowski | 425-442-9209 | skype: thomas.taranowski | baringforge.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: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Question about best practices for large Multi-stage builds
Dan, How did you end up handling the precompiled dependencies? Did you use a dependency management system, such as ivy, or roll your own system? Thomas Taranowski | 425-442-9209 | skype: thomas.taranowski | baringforge.com On Mon, Aug 26, 2013 at 12:21 PM, Dan Kegel d...@kegel.com wrote: On Mon, Aug 26, 2013 at 12:16 PM, Thomas Taranowski t...@baringforge.com wrote: Now, I'm trying to implement a multi-stage build which does the following: 1) builds some external third-party dependencies. 2) auto-generate some code 3) build the source 4) package the result To do this, I'd like to implement some top level build targets in cmake, so I can run make auto_generate, make third_party, etc. I can see a couple different potential ways to do this, but I've not been able to google up documentation that discusses the best method for implementing this. How are folks generally approaching this top level build target issue? I tried to do it all in cmake for a while, but then I gave up and use a shell script or something to drive the inner builds. The problem was, some developers wanted to not build everything; they wanted precompiled versions of the other packages. And it was just too painful for some devs to build one way, and others to build another way. - Dan -- 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: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Question about best practices for large Multi-stage builds
Matthew, I tend to agree with you that 2 would not generally be a target. However, there are external factors at play that I haven't mentioned. For one, in our environment we'd like to pull the auto generated code into a code review tool, and to mechanize that we have a commit daemon running that can run the auto generate rule, and commit the difference to a review-only branch for inspection purposes. It's true that it could be accomplished by doing the all build, and grabbing the output after the build was complete, it just takes alot longer. Thomas Taranowski | 425-442-9209 | skype: thomas.taranowski | baringforge.com On Mon, Aug 26, 2013 at 12:36 PM, Matthew Woehlke matthew.woeh...@kitware.com wrote: On 2013-08-26 15:16, Thomas Taranowski wrote: I have the following build structure: workspace/ CMakeLists.txt # top level cmake component_a/ CMakeLists.txt # component cmake src/ # source in here component_b/ CMakeLists.txt # component cmake src/ # source in here Now, I'm trying to implement a multi-stage build which does the following: 1) builds some external third-party dependencies. 2) auto-generate some code 3) build the source 4) package the result In my experience... 1-3 and 4 are covered by the 'all' and 'package' targets, respectively. If your dependencies are properly expressed, I would not expect 2 to be a target, and the parts of 1 needed by 2-3 will be built automatically. (If you really want, it is trivial to add a custom target that depends on whatever third-party pieces you have.) I've seen two common methods for dealing with third-party packages: build them in the same CMake hierarchy as everything else, or build them as external projects. In the latter case, your main project must also be an external project in order to ensure the third party pieces are fully built before the main part of your project configures. In either case, there is usually an option to use the 'internal' version of a third-party component or to supply an external version. The main project relies on find modules / configs to find third party components, and your build driver (i.e. the root CMakeLists.txt) sets whatever variables are necessary to use or find the internal version so that the consumers thereof don't need to care about the difference. -- Matthew -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/**CMake_FAQhttp://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.htmlhttp://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/**consulting.htmlhttp://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/**training.htmlhttp://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/** opensource/opensource.htmlhttp://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/**listinfo/cmakehttp://www.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: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Question about best practices for large Multi-stage builds
Craig, Thanks for the info. I went back and read through your post, and our build has many of the same issues you are facing. For our project I ended up keeping all dependencies in the context of the project workspace, and am not using the find* modules to fulfill dependencies. Thomas Taranowski | 425-442-9209 | skype: thomas.taranowski | baringforge.com On Mon, Aug 26, 2013 at 4:14 PM, Craig Scott audiofana...@gmail.com wrote: Thomas, there are a lot of parallels between your scenario and the one I just posted a question about yesterday (see subject line One build, multiple compilers and packages). One of the two scenarios that Matthew suggested is the one we've used to handle the external third party dependencies - we use ExternaProject for that. Matthew's comment that your main project then needs to be an ExternalProject as well is only partially correct though. If your main project(s) use find_library(), find_program(), etc. to work out where the external third party targets get built, then you would need to somehow ensure that the external project(s) is fully built when the main project undergoes its configure step. Making your main project an external project as well would accomplish this, but we found that making everything into a set of external projects was less than ideal (I'll save the details for that other thread if people want more info). Rather than using find_XXX() for the external third part bits, since you know where they will be in the build tree, you can instead use that knowledge and construct the necessary variables directly at configure time (which Matthew also suggested). This won't require the targets to have been built yet, but it does mean you will then have to handle any platform differences, etc. yourself (eg different library or executable prefixes and suffixes). On Tue, Aug 27, 2013 at 7:36 AM, Matthew Woehlke matthew.woeh...@kitware.com wrote: On 2013-08-26 16:37, Thomas Taranowski wrote: I tend to agree with you that 2 would not generally be a target. However, there are external factors at play that I haven't mentioned. For one, in our environment we'd like to pull the auto generated code into a code review tool, and to mechanize that we have a commit daemon running that can run the auto generate rule, and commit the difference to a review-only branch for inspection purposes. It's true that it could be accomplished by doing the all build, and grabbing the output after the build was complete, it just takes alot longer. In that case, you could always add another custom target that depends on all of your generated output files (as well as the targets using the same depending on them), similar to a 'build all third party' target. -- Matthew -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/**CMake_FAQhttp://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.htmlhttp://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/**consulting.htmlhttp://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/**training.htmlhttp://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/** opensource/opensource.htmlhttp://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/**listinfo/cmakehttp://www.cmake.org/mailman/listinfo/cmake -- Craig Scott Melbourne, Australia -- 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: http://www.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: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMAKE_C_FLAGS and CMAKE_C_COMPILER cross compilation woe
Thanks for the response Andreas. For those poor souls who come after,
the solution is to do the following:
set(CMAKE_C_FLAGS -mmcu=msp430fr5739 -D__MSP430FR5739__
-ffunction-sections -fdata-sections -DGCC_MSP430 -Wall -g -std=c99
CACHE STRING FORCE)
Using the FORCE attribute forces the specified cflags to take effect.
Thomas Taranowski
Certified netburner consultant
baringforge.com
On Tue, May 14, 2013 at 11:55 AM, Andreas Mohr a...@lisas.de wrote:
Hi,
On Tue, May 14, 2013 at 02:38:17PM -0400, cmake-requ...@cmake.org wrote:
Date: Tue, 14 May 2013 10:02:56 -0700
From: Thomas Taranowski t...@baringforge.com
I am running into a situation when cross compiling where I cannot get
cmake to emit the write CFLAGS for my cross-compilation toolchain
correctly.
If I force the C compiler, via the CMakeForceCompiler mechanism, the
CMAKE_C_FLAGS do not get passed to gcc during the build.
Example make VERBOSE=true snapshot. Note there are no CFLAGS, only
include paths:
/usr/local/msp430/bin/msp430-gcc
-I/home/tom/src/t3gtb.1/t3_i2c_mm/public
-I/home/tom/src/t3gtb.1/t3_i2c_mm/src/msp430
-I/home/tom/src/t3gtb.1/t3_i2c_mm/src-o
CMakeFiles/t3_i2c_mm_support.dir/src/msp430/t3g_bsp.c.obj -c
/home/tom/src/t3gtb.1/t3_i2c_mm/src/msp430/t3g_bsp.c
Now, I can eliminate the need to force by passing in a -mmcu option
(required for this processor to find the correct link map), which
allows the TRY_COMPILE process to pass. So I set:
set(CMAKE_C_COMPILER ${CROSS_COMPILE}gcc ${CMAKE_C_FLAGS})
This works to allow cmake to do it's thing and figure out what it
needs to about the toolchain. However, it seems as though the cflags
is now fixed, because the include_directories directive has absolutely
no effect. It's as if cmake thinks that if I pass in some additional
flags to the CMAKE_C_COMPILER, that it can no longer append anything
to cflags.
This is the usual CMAKE_lang_FOO per-LANGUAGE mechanism
(for pre-defined languages and custom-setup ones), e.g. CMAKE_C_COMPILER,
..._LINKER etc. variables.
I believe you're missing the usual (and usually existing!) *extension* parts
within these expressions, which would be the ... parts (FLAGS etc.).
For details, see all the Platform setup modules within CMake's
pre-installed modules, i.e. INSTALL_PREFIX/share/cmake-VER/Modules/Platform/ ,
since *this* is where the game gets played, i.e. where all the magic
happens, thus that is the authoritative place to start investigating about
custom platform setup questions.
HTH,
Andreas Mohr
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] CMAKE_C_FLAGS and CMAKE_C_COMPILER cross compilation woe
I am running into a situation when cross compiling where I cannot get
cmake to emit the write CFLAGS for my cross-compilation toolchain
correctly.
If I force the C compiler, via the CMakeForceCompiler mechanism, the
CMAKE_C_FLAGS do not get passed to gcc during the build.
Example make VERBOSE=true snapshot. Note there are no CFLAGS, only
include paths:
/usr/local/msp430/bin/msp430-gcc
-I/home/tom/src/t3gtb.1/t3_i2c_mm/public
-I/home/tom/src/t3gtb.1/t3_i2c_mm/src/msp430
-I/home/tom/src/t3gtb.1/t3_i2c_mm/src-o
CMakeFiles/t3_i2c_mm_support.dir/src/msp430/t3g_bsp.c.obj -c
/home/tom/src/t3gtb.1/t3_i2c_mm/src/msp430/t3g_bsp.c
Now, I can eliminate the need to force by passing in a -mmcu option
(required for this processor to find the correct link map), which
allows the TRY_COMPILE process to pass. So I set:
set(CMAKE_C_COMPILER ${CROSS_COMPILE}gcc ${CMAKE_C_FLAGS})
This works to allow cmake to do it's thing and figure out what it
needs to about the toolchain. However, it seems as though the cflags
is now fixed, because the include_directories directive has absolutely
no effect. It's as if cmake thinks that if I pass in some additional
flags to the CMAKE_C_COMPILER, that it can no longer append anything
to cflags.
Example output from make VERBOSE=true. Note the flags now exist, but
no include paths:
/usr/local/msp430/bin/msp430-gcc -mmcu=msp430fr5739
-D__MSP430FR5739__ -ffunction-sections -fdata-sections -DGCC_MSP430
-Wall -g -std=c99 -mmcu=msp430fr5739
CMakeFiles/test_manager_main.dir/src/test_manager_main.c.obj -o
test_manager_main
My ideal solution would be to get cmake to allow for appending include
directories and other flags to the compiler invocation, even though I
specified the magic -mmcu to allow the gcc to compile for my target.
Any ideas on what I'm doing wrong, or an alternate path to try that
I've overlooked? A simplified version of my CMakeLists.txt is pasted
below.
set(CMAKE_SYSTEM_NAME Generic)
# Base directory for the msp toolchain
set(MSPBASE $ENV{MSPBASE})
# the name of the target operating system
set(CMAKE_SYSTEM_VERSION 1)
set(CMAKE_SYSTEM_PROCESSOR msp430)
set(CMAKE_CROSSCOMPILING TRUE)
set(CROSS_COMPILE msp430-)
# which C and C++ compiler to use
set(CMAKE_C_FLAGS -mmcu=msp430fr5969 -D__MSP430FR5969__
-ffunction-sections -fdata-sections -DGCC_MSP430 -Wall -g -std=c99)
set(CMAKE_C_COMPILER ${CROSS_COMPILE}gcc ${CMAKE_C_FLAGS})
set(CMAKE_LINKER ${CROSS_COMPILE}gcc)
set(CMAKE_CXX_FLAGS -mmcu=msp430fr5969 -D__MSP430FR5969__
-ffunction-sections -fdata-sections -DGCC_MSP430 -Wall -fno-exceptions
-fno-rtti -fno-enforce-eh-specs -fnostdlib)
set(CMAKE_CXX_COMPILER ${CROSS_COMPILE}g++ ${CMAKE_CXX_FLAGS})
set(CMAKE_EXE_LINKER_FLAGS -mmcu=msp430fr5969)
set(CMAKE_FIND_ROOT_PATH /usr/local/msp430/msp430)
# adjust the default behaviour of the FIND_XXX() commands:
# search headers and libraries in the target environment, search
# programs in the host environment
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
Thanks,
Tom
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
