Re: [CMake] Resetting CMAKE_Fortran_FLAGS for a specific file

Hi Marco. Sane compilers allow later command-line options to override earlier ones, so what you're doing should be fine. Unfortunately, I know some Fortran compilers are not sane in this regard. If you really need to solve this by explicitly modifying the global list for a particular file, the on

Re: [CMake] Resetting CMAKE_Fortran_FLAGS for a specific file

Hi Petr, thanks, very informative! 2014-08-13 9:20 GMT+0200, Petr Kmoch : > Hi Marco. > > Sane compilers allow later command-line options to override earlier ones, > so what you're doing should be fine. Unfortunately, I know some Fortran > compilers are not sane in this regard. Here, I would r

[CMake] ExternalProject and install dir

Hi, I’m using ExternalProject, but the documentation does not really reflect what I am witnessing I have a Project X which is included through ExternalProject in Project A Project X has no PREFIX set in its CMakeLists I include project X like this: include(ExternalProject) ExternalProj

Re: [CMake] ExternalProject and install dir

If x is a CMake-driven project, you'll also need to explicitly set CMAKE_INSTALL_PREFIX when configuring. If not, there's likely a "--prefix" arg for configuring... One of those also has to be set to install to a non-default location. The PREFIX arg for ExternalProject is only used to organize

Re: [CMake] ExternalProject and install dir

See, for example: https://github.com/OpenChemistry/openchemistry/blob/master/CMakeLists.txt#L24 A common CMAKE_INSTALL_PREFIX is used for all OpenChemistry ExternalProject builds that are driven by CMake. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at

Re: [CMake] ExternalProject and install dir

I see thanks, so install_dir has a different meaning than the eventual install dir of the external project, I thought there would be some ‘magic’ where the ExternalProject functions would override the the prefix of, in this case, project x. I still have one issue, perhaps I should start a new

Re: [CMake] Resetting CMAKE_Fortran_FLAGS for a specific file

On Wed, Aug 13, 2014 at 3:18 AM, marco restelli wrote: > Hi Petr, >thanks, very informative! > > 2014-08-13 9:20 GMT+0200, Petr Kmoch : > > Hi Marco. > > > > Sane compilers allow later command-line options to override earlier ones, > > so what you're doing should be fine. Unfortunately, I kno

Re: [CMake] ExternalProject and install dir

If project Y needs to link to project X, you could build project Y with ExternalProject_Add and list project X in the DEPENDS parameter. http://www.cmake.org/cmake/help/v3.0/module/ExternalProject.html On Wed, Aug 13, 2014 at 9:39 AM, Hans van den Bogert wrote: > I see thanks, so install_dir h

Re: [CMake] Resetting CMAKE_Fortran_FLAGS for a specific file

2014-08-13 15:53 GMT+0200, Mark Abraham : > On Wed, Aug 13, 2014 at 3:18 AM, marco restelli > wrote: > >> Hi Petr, >>thanks, very informative! >> >> 2014-08-13 9:20 GMT+0200, Petr Kmoch : >> > Hi Marco. >> > >> > Sane compilers allow later command-line options to override earlier >> > ones, >>

Re: [CMake] Resetting CMAKE_Fortran_FLAGS for a specific file

On Wed, Aug 13, 2014 at 7:12 AM, marco restelli wrote: > 2014-08-13 15:53 GMT+0200, Mark Abraham : > > On Wed, Aug 13, 2014 at 3:18 AM, marco restelli > > wrote: > > > >> Hi Petr, > >>thanks, very informative! > >> > >> 2014-08-13 9:20 GMT+0200, Petr Kmoch : > >> > Hi Marco. > >> > > >> > Sa

Re: [CMake] Resetting CMAKE_Fortran_FLAGS for a specific file

2014-08-13 16:16 GMT+0200, Mark Abraham : > On Wed, Aug 13, 2014 at 7:12 AM, marco restelli > wrote: > >> 2014-08-13 15:53 GMT+0200, Mark Abraham : >> > On Wed, Aug 13, 2014 at 3:18 AM, marco restelli >> > wrote: >> > >> >> Hi Petr, >> >>thanks, very informative! >> >> >> >> 2014-08-13 9:20 G

Re: [CMake] Help cmake First project

Are these actually C++ files? If so then they should really have a C++ extension (like .cp or .cxx). It may be a good idea in general since other build tools may run in to the same sort of issue of assuming they are C files. A few other tips: first, by placing all your source files in a list var

[CMake] Generator-independent incremental CMake run

Hello, For our Continuous Integration tests we need fast incremental builds (only build what has changed). This also includes that CMake only has to run if necessary (some CMakeLists.txt changed). It seems there is no beautiful/portable/generator-independent way to do this?! Fortunately we m

Re: [CMake] Generator-independent incremental CMake run

On Wed, 2014-08-13 at 21:40 +0200, Nagger wrote: > Does anyone already came up with a good solution? Isn't this a common > problem? I'm not sure about the other generators, but the makefile generator has this built-in; that is, if the makefiles detect that a cmake file has changed it will re-run

Re: [CMake] Generator-independent incremental CMake run

Am 13.08.2014 21:59, schrieb Paul Smith: On Wed, 2014-08-13 at 21:40 +0200, Nagger wrote: Does anyone already came up with a good solution? Isn't this a common problem? I'm not sure about the other generators, but the makefile generator has this built-in; that is, if the makefiles detect that

Re: [CMake] Generator-independent incremental CMake run

On 13. August 2014 21:40:34 MESZ, Nagger wrote: >But what I really miss is an "--update" option for CMake which is doing > >all the work (updating if possible, configuring if necessary) >internally. It would use the implementation of 'cmake --build' to >trigger a re-configure and if that is no