[cmake-developers] [CMake 0015536]: Include directories for .mod files produced with IBM XL Fortran
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15536 == Reported By:Paul Romano Assigned To: == Project:CMake Issue ID: 15536 Category: CMake Reproducibility:have not tried Severity: minor Priority: normal Status: new == Date Submitted: 2015-04-26 06:41 EDT Last Modified: 2015-04-26 06:41 EDT == Summary:Include directories for .mod files produced with IBM XL Fortran Description: When the IBM XL Fortran compiler is detected, the following is set: set(CMAKE_Fortran_MODDIR_Flag -qmoddir=) According to the xlf documentation, this flag specifies where .mod files produced should be placed. However, unlike the -J option for gfortran and the -module option for ifort, -qmoddir does not tell the compiler to search for module files in this directory; for that, one also needs to specify -I. Thus, in order to work properly, you really need something like: -qmoddir=includedir -Iincludedir Additional Information: I'm using the IBM XL Fortran 14.1 for BlueGene/Q compiler on the Mira supercomputer at Argonne National Laboratory. == Issue History Date ModifiedUsername FieldChange == 2015-04-26 06:41 Paul RomanoNew Issue == -- 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://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] CMAKE_TOOLCHAIN_FILE and ExternalProject_Add
Hi,
I'm using cmake and CMAKE_TOOLCHAIN_FILE to build the project and it's
dependencies. Some toolchain files have additional options (like API
version, target architecture, linker type, etc.) which you need to
pass to cmake command with -D in addition to the
-DCMAKE_TOOLCHAIN_FILE= itself.
So when you want to build some dependency with ExternalProject_Add()
it's not enough to pass the same CMAKE_TOOLCHAIN_FILE. You also need
to explicitly specify all other toolchain variables that you care
about. That means that each time you start to override another
toolchain variables or add a new toolchain, you need to carefully add
proper variable forwardings to each ExternalProject_Add() call. This
is not convenient and error prone.
What do you think about formalizing toolchains a bit further? For
example, it would be nice to have a way to get all variables (with
their values) that are relevant for the current toolchain. Consider:
ExternalProject_Add(websockets_ep
CMAKE_ARGS
-DCMAKE_TOOLCHAIN_FILE:string=${CMAKE_TOOLCHAIN_FILE}
-DCMAKE_TOOLCHAIN_ARGS:string=${CMAKE_TOOLCHAIN_ARGS})
Where ${CMAKE_TOOLCHAIN_ARGS} expands to VAR1=VAL1;VAR2=VAL2; (I
realize that will not work like that, but conceptually) which defines
toolchain configuration.
For example, well behaved toolchain file could be asked to mark each
configuration variable:
toolchain_option(ANDROID_NATIVE_API_LEVEL)
so CMake after processing of a toolchain file can have a list of all
relevant variables. Or maybe CMake can track all variables touched
by the toolchain file.
What do you think about that?
--
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://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMAKE_TOOLCHAIN_FILE and ExternalProject_Add
Because it will be an ad-hoc solution. Also each time I will start
using a new toolchain file (for another device/platform) I will need
to modify that wrapper script. And each time I will override some
toolchain variable I will need to look into that wrapper to verify
that this variable will be forwarded. Wouldn't it be nice if there was
a simple way to tell build this external project the same way as a
main one?
I'm not saying that the problem is unsolvable. I'm saying that right
now CMake is not very convenient for projects with a lot of external
dependencies. And specifying toolchain and it's options is a one
aspect of it (not the most important, though).
On Sun, Apr 26, 2015 at 5:36 PM, David Cole dlrd...@aol.com wrote:
Why wouldn't you just write your own toolchain wrapper file which
has all the variables you speak of, but also includes the real
toolchain file, and then use the wrapper as your CMAKE_TOOLCHAIN_FILE
value ... ?
D
On Sun, Apr 26, 2015 at 7:32 PM, Andrey Pokrovskiy
wonder.m...@gmail.com wrote:
Hi,
I'm using cmake and CMAKE_TOOLCHAIN_FILE to build the project and it's
dependencies. Some toolchain files have additional options (like API
version, target architecture, linker type, etc.) which you need to
pass to cmake command with -D in addition to the
-DCMAKE_TOOLCHAIN_FILE= itself.
So when you want to build some dependency with ExternalProject_Add()
it's not enough to pass the same CMAKE_TOOLCHAIN_FILE. You also need
to explicitly specify all other toolchain variables that you care
about. That means that each time you start to override another
toolchain variables or add a new toolchain, you need to carefully add
proper variable forwardings to each ExternalProject_Add() call. This
is not convenient and error prone.
What do you think about formalizing toolchains a bit further? For
example, it would be nice to have a way to get all variables (with
their values) that are relevant for the current toolchain. Consider:
ExternalProject_Add(websockets_ep
CMAKE_ARGS
-DCMAKE_TOOLCHAIN_FILE:string=${CMAKE_TOOLCHAIN_FILE}
-DCMAKE_TOOLCHAIN_ARGS:string=${CMAKE_TOOLCHAIN_ARGS})
Where ${CMAKE_TOOLCHAIN_ARGS} expands to VAR1=VAL1;VAR2=VAL2; (I
realize that will not work like that, but conceptually) which defines
toolchain configuration.
For example, well behaved toolchain file could be asked to mark each
configuration variable:
toolchain_option(ANDROID_NATIVE_API_LEVEL)
so CMake after processing of a toolchain file can have a list of all
relevant variables. Or maybe CMake can track all variables touched
by the toolchain file.
What do you think about that?
--
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://public.kitware.com/mailman/listinfo/cmake-developers
--
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://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMAKE_TOOLCHAIN_FILE and ExternalProject_Add
I realize that sometimes dependencies are necessary.
But.
There's a very strong argument to be made that projects should not
have a lot of external dependencies.
If you really need to tell an ExternalProject build this external
project the same way as the main one, you should probably write code
(perhaps a wrapper of ExternalProject itself) that literally passes
the entire CMakeCache.txt of the main project down to the external
project.
I really don't see how you solve the problem by having a toolchain
file and some arbitrary set of variables to be passed down. Either you
have to put the CMAKE_TOOLCHAIN_ARGS into the toolchain file itself,
or you have to specify the complete set of what defines
CMAKE_TOOLCHAIN_ARGS. If you have a set, how do you add to it? Why not
just have them in the file? If the set changes from project to project
or toolchain to toolchain, then how can you define it so that it's
generally useful?
D
On Sun, Apr 26, 2015 at 8:53 PM, Andrey Pokrovskiy
wonder.m...@gmail.com wrote:
Because it will be an ad-hoc solution. Also each time I will start
using a new toolchain file (for another device/platform) I will need
to modify that wrapper script. And each time I will override some
toolchain variable I will need to look into that wrapper to verify
that this variable will be forwarded. Wouldn't it be nice if there was
a simple way to tell build this external project the same way as a
main one?
I'm not saying that the problem is unsolvable. I'm saying that right
now CMake is not very convenient for projects with a lot of external
dependencies. And specifying toolchain and it's options is a one
aspect of it (not the most important, though).
On Sun, Apr 26, 2015 at 5:36 PM, David Cole dlrd...@aol.com wrote:
Why wouldn't you just write your own toolchain wrapper file which
has all the variables you speak of, but also includes the real
toolchain file, and then use the wrapper as your CMAKE_TOOLCHAIN_FILE
value ... ?
D
On Sun, Apr 26, 2015 at 7:32 PM, Andrey Pokrovskiy
wonder.m...@gmail.com wrote:
Hi,
I'm using cmake and CMAKE_TOOLCHAIN_FILE to build the project and it's
dependencies. Some toolchain files have additional options (like API
version, target architecture, linker type, etc.) which you need to
pass to cmake command with -D in addition to the
-DCMAKE_TOOLCHAIN_FILE= itself.
So when you want to build some dependency with ExternalProject_Add()
it's not enough to pass the same CMAKE_TOOLCHAIN_FILE. You also need
to explicitly specify all other toolchain variables that you care
about. That means that each time you start to override another
toolchain variables or add a new toolchain, you need to carefully add
proper variable forwardings to each ExternalProject_Add() call. This
is not convenient and error prone.
What do you think about formalizing toolchains a bit further? For
example, it would be nice to have a way to get all variables (with
their values) that are relevant for the current toolchain. Consider:
ExternalProject_Add(websockets_ep
CMAKE_ARGS
-DCMAKE_TOOLCHAIN_FILE:string=${CMAKE_TOOLCHAIN_FILE}
-DCMAKE_TOOLCHAIN_ARGS:string=${CMAKE_TOOLCHAIN_ARGS})
Where ${CMAKE_TOOLCHAIN_ARGS} expands to VAR1=VAL1;VAR2=VAL2; (I
realize that will not work like that, but conceptually) which defines
toolchain configuration.
For example, well behaved toolchain file could be asked to mark each
configuration variable:
toolchain_option(ANDROID_NATIVE_API_LEVEL)
so CMake after processing of a toolchain file can have a list of all
relevant variables. Or maybe CMake can track all variables touched
by the toolchain file.
What do you think about that?
--
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://public.kitware.com/mailman/listinfo/cmake-developers
--
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:
