[CMake] Toolchain file for TI in CMake 3.10: how do I override compiler options and specify tools?
I am trying to use CMake (3.10) to build an ANSI C project that may be
compiled on PC with eg. GCC, but also needs to compile with Texas
Instruments' compilers for their microprocessors. So I have about a million
questions.
According to[1] it seems like the way to do this is via a toolchain file.
So I'm trying to write a toolchain file to use TI's compiler/linker/etc,
which do not (always) take the same arguments as eg. GCC or Clang.
Is there a complete list of tools I can override in a toolchain file?
Specifically, I want to set the C compiler, C++ compiler, assembler and
linker. I know about CMAKE_C(XX)_COMPILER, but what about the others? Are
they documented anywhere? (I could guess, but I don't think that's wise.)
As I mentioned, TI's tools aren't the same as GCC, so I need to pare back a
lot of options and start from almost-scratch (there are some
commonalities). Options like "-D" and "-I" are fine, which is good because
then eg. target_include_directories() still works. But certain other flags
are just going to cause errors. How do I completely remove all compile
flags from the generated Makefiles and replace them with my own? I can do
this:
set(CMAKE_C_FLAGS ${MINIMAL_FLAGS} CACHE STRING "" FORCE)
set(CMAKE_C_FLAGS_DEBUG ${MINIMAL_FLAGS} CACHE STRING "" FORCE)
set(CMAKE_C_FLAGS_RELEASE ${MINIMAL_FLAGS} CACHE STRING "" FORCE)
set(CMAKE_C_FLAGS_RELWITHDEBINFO ${MINIMAL_FLAGS} CACHE STRING "" FORCE)
set(CMAKE_C_FLAGS_MINSIZEREL ${MINIMAL_FLAGS} CACHE STRING "" FORCE)
But I *still* see flags in the generated makefiles that I didn't put there
such as "--compile_only" and "--c_file=...". How do I get rid of these and
specify what's correct for my toolchain? (Also, why do I need the CACHE
STRING "" FORCE options? I pulled that out of various Stackoverflow posts
but I have no idea why it's necessary. Is that documented? What about the
configurations... where are they listed? Do I have them all?)
(I keep asking "is this documented anywhere" because I like to provide
references in code for future maintainers. I'm not trying to be unkind.
Maybe once I know enough I can volunteer to write any missing docs myself.)
How do I add default flags that involve the source file name eg. for a file
"main.c" I want to have a C compiler flag "--some_option='main.x'"?
Finally, this really seems like a lot of work despite the fact that
toolchain files are (I thought) meant to be the way to define a different
toolchain. It really feels like I'm swimming against the tide here. Is
there another, more-CMake-ish way to accomplish what I'm trying to do?
[1]
https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/CrossCompiling
Thanks for any help.
- Jason
--
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] Ensuring an external project is built and installed before trying to call "find_package" on it
On Sat, Feb 23, 2019 at 4:14 PM Timothy Wrona wrote:
> I am working on a CMake project that depends on a couple other projects I
> have previously written. I would like to include those other projects using
> "ExternalProject_Add", but I am having some issues.
>
> The basic layout of the project is this:
>
> cmake_minimum_required(VERSION 3.14.0)
>
> project(ProjectWithDependencies)
>
> include(ExternalProject)
> ExternalProject_Add(Dependency1
> GIT_REPOSITORY
> )
> ExternalProject_Add(Dependency2
> GIT_REPOSITORY
> )
>
> find_package(Dependency1 Required)
> find_package(Dependency2 Required)
>
> # Use targets
>
> I was under the assumption that "ExternalProject_Add" would automatically
> build and install the dependencies before getting to the "find_package"
> calls (they are CMake projects so the default build and install commands
> should be fine) but this doesn't seem to be how it works.
>
> When I get to "find_package" it fails because the dependency hasn't been
> installed yet.
>
> How can I ensure that the dependencies are fully compiled and installed
> before attempting to find them? (Note: FetchContent doesn't work here
> because the two projects "Dependency1" and "Dependency2" have targets with
> the same name which causes FetchContent to fail.)
>
> Any help is appreciated.
>
find_package() requires that the dependencies have been built already, as
you've noted. When CMake runs and processes your example CMakeLists.txt
file, it sets up the build rules for Dependency1 and Dependency2, but they
won't actually be configured, built and installed until you build the main
project. Since your find_package() calls will be processed during the
configure stage of the main project (i.e. before the build stage), it's too
early.
To address this, you need to make your main project a true superbuild where
it basically contains nothing more than a set of ExternalProject_Add()
calls. Rather than putting the find_package() calls and use of targets
directly in the main build, you can add it as another sub-build. Note that
this will mean that none of the targets you define in the mainBuild will be
visible as targets in your top level superbuild project. I'd also advise
you to override the default install location of your dependencies.
Otherwise they will typically try to install to a system-wide location,
which is not usually a good thing. Putting it together, the top level
superbuild project would look something like this:
cmake_minimum_required(VERSION 3.14.0)
project(ProjectWithDependencies)
set(installDir ${CMAKE_CURRENT_BINARY_DIR}/install)
include(ExternalProject)
ExternalProject_Add(Dependency1
GIT_REPOSITORY
INSTALL_DIR${installDir}
CMAKE_ARGS -DCMAKE_INSTALL_PREFIX:PATH=
)
ExternalProject_Add(Dependency2
GIT_REPOSITORY
INSTALL_DIR${installDir}
CMAKE_ARGS -DCMAKE_INSTALL_PREFIX:PATH=
)
ExternalProject_Add(mainBuild
SOURCE_DIR
INSTALL_DIR ${installDir}
DEPENDS Dependency1 Dependency2
CMAKE_ARGS -DCMAKE_INSTALL_PREFIX:PATH=
-DCMAKE_PREFIX_PATH:PATH=
)
Or you could make the superbuild a completely separate repo and then use
GIT_REPOSITORY rather than SOURCE_DIR for the "mainBuild" part.
--
Craig Scott
Melbourne, Australia
https://crascit.com
Get the hand-book for every CMake user: Professional CMake: A Practical
Guide
[CMake] Ensuring an external project is built and installed before trying to call "find_package" on it
I am working on a CMake project that depends on a couple other projects I have previously written. I would like to include those other projects using "ExternalProject_Add", but I am having some issues. The basic layout of the project is this: cmake_minimum_required(VERSION 3.14.0) project(ProjectWithDependencies) include(ExternalProject) ExternalProject_Add(Dependency1 GIT_REPOSITORY ) ExternalProject_Add(Dependency2 GIT_REPOSITORY ) find_package(Dependency1 Required) find_package(Dependency2 Required) # Use targets I was under the assumption that "ExternalProject_Add" would automatically build and install the dependencies before getting to the "find_package" calls (they are CMake projects so the default build and install commands should be fine) but this doesn't seem to be how it works. When I get to "find_package" it fails because the dependency hasn't been installed yet. How can I ensure that the dependencies are fully compiled and installed before attempting to find them? (Note: FetchContent doesn't work here because the two projects "Dependency1" and "Dependency2" have targets with the same name which causes FetchContent to fail.) Any help is appreciated. Thanks, Tim -- 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] Automatically updating Doxygen documentation and making it readily available to users with CMake
Le jeu. 21 févr. 2019 à 06:19, Timothy Wrona a écrit : > > Either way having it as an "index.html" file somewhere on the hard-disk is > not very intuitive. It would make much more sense for it to be on a web > server where you can access it with a sensible URL. > Unless it's linked from some front page you know users often go to, I don't see why http://some.server/doc/mylibrary/index.html is more "intuitive" than file://some/directory/mylibrary/index.html. The difference between the two is sharing vs not, it's not about "intuitiveness". BTW your questions are really not clear on the topic of sharing. The problem of a developer building documentation without realizing it is very different from the problem of user not building anything, even when the latter is not curious about documentation either. PS: I suggested some cmake fine-tuning on stackoverflow. -- 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] CUDA language support with host compiler flags
Hi All!
I am trying to compile CUDA code with controlling both host and device
compiler flags.
Currently my CMakeLists.txt looks like:
```
cmake_minimum_required(VERSION 3.8) # CUDA language support
project(CUDA_test LANGUAGES CXX CUDA)
if (MSVC)
string(REGEX REPLACE "/W[0-9]" "" CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS})
endif (MSVC)
set(Hdrs)
set(Srcs Main.cu)
add_executable(${PROJECT_NAME} ${Hdrs} ${Srcs})
target_include_directories(${PROJECT_NAME} PRIVATE
${CMAKE_CURRENT_SOURCE_DIR})
target_compile_options(${PROJECT_NAME} PRIVATE
$<$,$>:-Wall -Wextra
-pedantic>
$<$:/W4>)
set_target_properties(${PROJECT_NAME} PROPERTIES
CUDA_SEPARABLE_COMPILATION ON
CUDA_STANDARD 14
CUDA_STANDARD_REQUIRED ON
CUDA_EXTENSIONS OFF
CXX_STANDARD 14
CXX_STANDARD_REQUIRED ON
CXX_EXTENSIONS OFF)
source_group ("Headers" FILES ${Hdrs})
source_group ("Sources" FILES ${Srcs})
```
However, when I compile the code I get the following error:
[1/3] Building CUDA object CMakeFiles/CUDA_test.dir/Main.cu.o
FAILED: CMakeFiles/CUDA_test.dir/Main.cu.o
/usr/bin/nvcc
-I/var/tmp/src/e75971a9-7e91-6137-abfa-df34048cc171/GCC-Debug-WSL -g
-Wall -Wextra -pedantic -std=c++14 -x cu -dc
/var/tmp/src/e75971a9-7e91-6137-abfa-df34048cc171/GCC-Debug-WSL/Main.cu
-o CMakeFiles/CUDA_test.dir/Main.cu.o && /usr/bin/nvcc
-I/var/tmp/src/e75971a9-7e91-6137-abfa-df34048cc171/GCC-Debug-WSL -g
-Wall -Wextra -pedantic -std=c++14 -x cu -M
/var/tmp/src/e75971a9-7e91-6137-abfa-df34048cc171/GCC-Debug-WSL/Main.cu
-MT CMakeFiles/CUDA_test.dir/Main.cu.o -o
CMakeFiles/CUDA_test.dir/Main.cu.o.d
nvcc fatal : Unknown option 'Wall'
ninja: build stopped: subcommand failed.
CMake seems to pass -Wall -Wextra -pedantic to the device compiler as
well, even though it is neither GNU nor Clang, but CUDA. How can I
specify warning and similar flags separatly for the host and device
compilers?
--
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
--
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
