[CMake] Idomatic cmake: Supporting gcc, icc, and clang with custom flags for each?

TCW wafflecode at protonmail.com
Wed May 18 13:20:26 EDT 2016


Chuck, Tim:

Thank you both for the help. I'll give these ideas a try and see how they shake out.

The "module" command is a new one to me. Looks like it can be helpful for a variety of tasks.

I do still wish cmake had a method to select a tool family that was:

1) Succinct (i.e. short to type)
2) Explicit (i.e. actually present as argument to cmake, not environment based.)
3) Workable by default (i.e. If tools are installed in default location, no need to modify my CMakeLists unless I actually need to change flags.)

Is this worth filing as a feature request? If so, any suggestions about how to word this?

Thanks again,
Waffle


-------- Original Message --------
Subject: Re: [CMake] Idomatic cmake: Supporting gcc, icc, and clang with custom flags for each?
Local Time: May 17, 2016 1:49 PM
UTC Time: May 17, 2016 5:49 PM
From: tim.gallagher at gatech.edu
To: chuck.atkins at kitware.com,wafflecode at protonmail.com,cmake at cmake.org



We do what Chuck showed inside our CMakeLists for different flags for each compiler.





To answer your other question, I prefer to use the shorter form:





> CC=icc FC=ifort CXX=icpc cmake /path/to/source





which sets the CC, FC and CXX environment variables only for that ccmake command without changing them in my global environment (using bash shell, it may work in others also). Once CMake has set the compilers, it doesn't change them so future calls can just be





> cmake ./





Usually when I have to do a lot of compiler jockeying, I set up the module system (common on HPC's to handle different software stacks) so I can just do something like:





> module load intel-compilers


> cmake /path/to/source





> module swap intel-compilers gnu-compilers


> cmake /path/to/source





and so on.





Tim







------


From: CMake <cmake-bounces at cmake.org> on behalf of TCW via CMake <cmake at cmake.org>
Sent: Tuesday, May 17, 2016 1:21 PM
To: Chuck Atkins
Cc: cmake at cmake.org
Subject: Re: [CMake] Idomatic cmake: Supporting gcc, icc, and clang with custom flags for each?


Hi Chuck,

Interesting. The flat list is not so bad i guess. (As an include.) I was thinking that cmake might support some kind of hierarchical platform definition system like Qt's qmake. (Not that it's without foibles either.)

On the compiler selection question I'm still wondering if normative cmake usage really is, for example:

cmake -D CMAKE_C_COMPILER=/opt/path/to/icc -D CMAKE_CXX_COMPILER=/opt/path/to/icpc ../path/to/src

That is would be as opposed to the much shorter (but purely imagineary):
cmake --tools=intel_16.0 ../path/to/src
or, cmake --tools=gcc_5.3 ../path/to/src
or, cmake --tools=gcc_6.1 ../path/to/src

Where "intel_16.0" and the like map to some locally defined path (and perhaps also flag) definitions.

Do folks really use the long form above? (perhaps wrapping it in a shell script or the like?)

As someone very to to cmake, I wonder if I'm missing some key insight in to normal cmake workflow, or if this kind of compiler selection is, in fact, rare enough to not be cleanly supported.

Thank you,
Waffle



-------- Original Message --------
Subject: Re: [CMake] Idomatic cmake: Supporting gcc, icc, and clang with custom flags for each?
Local Time: May 17, 2016 9:47 AM
UTC Time: May 17, 2016 1:47 PM
From: chuck.atkins at kitware.com
To: wafflecode at protonmail.com
CC: cmake at cmake.org














Hi TCW,
A typical approach for this is in the top level CMakeLists.txt to have:

include(CompilerFlags)

And then you can isolate the detection and specialization logic in a separate CompilerFlags.cmake:

if(CMAKE_COMPILER_IS_GNUC)
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS" -extra --gcc-options")
elseif(CMAKE_C_COMPILER_ID MATCHES "Intel")
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS" -extra --icc-options")
elseif(CMAKE_C_COMPILER_ID MATCHES "PGI)
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS" -extra --pgcc-options")
elseif(MSVC)
if(MSVC_VERSION GREATER_THAN 1700)
...
elseif(...)
...
endif()
endif()

And then similarly for C++.












- Chuck


On Tue, May 17, 2016 at 1:49 AM, TCW via CMake <cmake at cmake.org> wrote:

Hello all,

On linux, what's the correct way to support building with several different C compilers, each with some extra compiler-specifc flags for Debug and Release modes? (Eventually I'll need to add Visual Studio on Windows too. )

For now, I'm following what's mentioned in the cmake FAQ and using CXX=/blah cmake, etc.

(From: [ https://cmake.org/Wiki/CMake_FAQ#How_do_I_use_a_different_compiler.3F](https://cmake.org/Wiki/CMake_FAQ#How_do_I_use_a_different_compiler.3F))

But this is getting quite cumbersome as I'm experimenting with different flags for each compiler, and I'd rather avoid polluting my fairly clean CMakeLists file with a bunch of if/else branches to set flags.

In the cmake manual I see reference to a -DCMAKE_TOOLCHAIN_FILE option, but this seems designed for embedded cross-compile scenarios. (Is that right?)

(From: [ https://cmake.org/cmake/help/v3.0/manual/cmake-toolchains.7.html](https://cmake.org/cmake/help/v3.0/manual/cmake-toolchains.7.html))

Basically, I'd like to succinctly choose among a set of (slightly) customized compiler choices.

For modern cmake usage what is the correct method? Can anybody point me to a well done example for a simple case like this?

Thank you!

tcw
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: [ http://www.cmake.org/Wiki/CMake_FAQ](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](http://cmake.org/cmake/help/support.html)
CMake Consulting: [ http://cmake.org/cmake/help/consulting.html](http://cmake.org/cmake/help/consulting.html)
CMake Training Courses: [ http://cmake.org/cmake/help/training.html](http://cmake.org/cmake/help/training.html)

Visit other Kitware open-source projects at [ http://www.kitware.com/opensource/opensource.html](http://www.kitware.com/opensource/opensource.html)

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160518/c99c9cc9/attachment.html>


More information about the CMake mailing list