[CMake] Replacing compiler flags for certain project subdirectories
Whitcomb, Mr. Tim
Tim.Whitcomb at nrlmry.navy.mil
Thu Mar 31 18:21:48 EDT 2011
Thanks, Arjen:
Unfortunately this goes beyond optimization flags, e.g. the odd directories out do their own byteswapping, so we can't use the command-line switch for byteswapped I/O that everything else needs.
Is another option to clear *all* flags at the top-level and re-instate them in the individual directories? It seems like that's overkill considering this is needed in so few directories.
I've been poking around with doing them as external projects, which seems to be promising but unfortunately the Cmake version installed on the systems I will be working on is at version
2.6 which doesn't support them.
Tim
> -----Original Message-----
> From: cmake-bounces at cmake.org
> [mailto:cmake-bounces at cmake.org] On Behalf Of Verweij, Arjen
> Sent: Thursday, March 31, 2011 2:38 AM
> To: 'cmake at cmake.org'
> Subject: Re: [CMake] Replacing compiler flags for certain project
> subdirectories
>
> Tim,
>
> I don't think cmake can facilitate this out of the box (to my
> knowledge). The problem is that some compilers and fortran code just
> don't mix with +O3 (blas, lapack).
>
> We have worked around it by reimplementing a mechanism from our old
> build system, where optimization for fortran c and cxx were
> parameterized, e.g. MDFC_OPT_LVLX (0-3 (up to 7 for Altix I think)).
> We have a wrapper function that sets COMPILE_FLAGS to this value with
> set_source_files_properties().
>
> The catch is that at top level you have to strip CMAKE_<LANG>_FLAGS
> from any optimization instruction:
>
> HPUX-IA64: set (CMAKE_C_LINK_FLAGS "+DSitanium2 +DD64
> +DO11.23 -Aa -Ae -D_HPUX_SOURCE +Z")
>
> Note: you may also have to redefine the default link flags.
>
> Hope this helps,
> Arjen
>
> >-----Original Message-----
> >From: cmake-bounces at cmake.org [mailto:cmake-bounces at cmake.org] On
> >Behalf Of Whitcomb, Mr. Tim
> >Sent: woensdag 30 maart 2011 20:00
> >To: 'cmake at cmake.org'
> >Subject: Re: [CMake] Replacing compiler flags for certain project
> >subdirectories
> >
> >Shortening to reduce wall-of-text:
> >
> >I have a Fortran project with a top-level CMakeLists.txt
> file with 47
> >add_subdirectory calls. Three of the subdirectories require a
> >different set of preprocessor definitions and compiler flags
> than the
> >other 47. I can add the preprocessor definitions, but am having
> >trouble with the compiler flags. I need to have a
> completely different
> >set in those subdirectories, so COMPILE_FLAGS target property won't
> >work as it augments what's already there.
> >
> >How can I replace (not extend) the compiler flags for these few
> >subdirectories?
> >
> >Tim
> >
> >> -----Original Message-----
> >> From: cmake-bounces at cmake.org
> >> [mailto:cmake-bounces at cmake.org] On Behalf Of Whitcomb, Mr. Tim
> >> Sent: Friday, March 25, 2011 3:18 PM
> >> To: 'cmake at cmake.org'
> >> Subject: [CMake] Replacing compiler flags for certain project
> >> subdirectories
> >>
> >> I'm in the process of adding Cmake-build capability to a Fortran
> >> project that currently follows a traditional recursive-make build
> >> structure. I've converted all the makefiles to
> CMakeLists.txt files
> >> and can now produce all the target libraries and executables with
> >> their dependencies correctly recognized. These dependencies have
> >> made a huge difference in allowing us to perform parallel
> builds and
> >> have the project ready to go *much* faster than before. I have a
> >> top-level CMakeLists.txt file that contains a few library searches
> >> (e.g. LAPACK, BLAS) and then an add_subdirectory call for each
> >> subdirectory in the project. Each subdirectory corresponds to a
> >> library and/or an executable.
> >>
> >> Now that the listing files contain all the sources files
> they need,
> >> my current task is to go through and set the proper
> >> compiler/preprocessor flags to match the original makefiles.
> >> We have several directories in our source tree that are auxiliary
> >> libraries that we store in our Subversion repository and build as
> >> part of our regular build process.
> >> The libraries that are built in these directories are
> compiled with
> >> different compiler flags and different preprocessor
> definitions than
> >> the rest of the project. I've been able to handle the
> preprocessor
> >> definitions by using add_definitions in the CMakeLists.txt
> files in
> >> the lower-level directories. I see based on reading through some
> >> past threads (including the recent "Different CMAKE_CXX_FLAGS for
> >> different executables") on this list and on some StackOverflow
> >> questions that the COMPILE_FLAGS target property is very close to
> >> what I need (and actually *was* what I needed in several
> cases) but
> >> only appends flags to those currently in use. What I
> need is to be
> >> able to define a new set of compile flags (i.e. "forget everything
> >> you were using before and use THIS set in this directory").
> >>
> >> I've started going through the documentation for Building External
> >> Projects[*] but the first line states that "[a]n "external
> project"
> >> is one that you can get the source code for, but does not readily
> >> build with a simple ADD_SUBDIRECTORY call in your CMakeLists.txt
> >> file." This feels like it's designed to solve a slightly
> different
> >> problem than what I'm trying to do - I have an
> add_subdirectory call
> >> in my CMakeLists.txt file - is the proper fix for this
> issue to make
> >> the pieces that require different flags external projects? Will
> >> making some of these libraries external projects mess with the
> >> dependency calculation?
> >>
> >> I'm just getting started and trying to wrap my head around the
> >> options available. What is the standard way of dealing with this
> >> issue? Is there anything I'm missing? Thank you for your
> >> assistance!
> >>
> >> Tim
> >> [w]
> >>
> >> [*]
> >> http://www.kitware.com/products/html/BuildingExternalProjectsW
> >> ithCMake2.8.html
> >_______________________________________________
> >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
>
More information about the CMake
mailing list