>
>
> We override the standard CMAKE_<LANG>_FLAGS (C CXX Fortran) and use it as a
> baseline. Then, for individual source files it is possible to override them
> in a separate file using:
>
>
Yes this is seemingly common practice in CMake land. The problem with this
approach is when using add_subdirectory on third party source these package
developers also set these (often with CACHE STRING "" FORCE - the reason why
I had to patch boost-cmake-1.41_0 and dcmtk, I use ExternalProject_ADD for
vtk, and vtk-edge, but this certainly the best solution) which can cause all
kinds of greif when these are included in an uber project. My approach is
to have a set of macros/functions which work as Boost.Build (bjam) projects
which can inherit properties from other parent projects. Which actually
makes the project( ) syntax somewhat useful. I currently have this working
(though not complete) with the last CMake strong hold being the use of these
variables. If I can overcome this I intend to submit these to Mantis bug
tracker as a feature request. This also allows the developer to reach
anywhere in any subproject and in any third party developer package and
change the build settings without having to patch (provided TPS developers
would use the convention).
I would like to do this without having to patch CMake and simply provide a
set of macro functions which could be included in future releases.
>
>
> set_source_files_properties(${CMAKE_BINARY_DIR}/path/to/file.f PROPERTIES
> GENERATED TRUE COMPILE_FLAGS "${FFLAG_OPT}")
>
>
>
COMPILE flags only appends to thoes already set CMAKE_... vars. I need a
way to override all the other vars on a per target basis.
_______________________________________________
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
