On 09/03/2010 04:13 PM, Belcourt, Kenneth wrote:
>
> On Sep 3, 2010, at 5:07 AM, Eric Noulard wrote:
>
>> 2010/9/3 Belcourt, Kenneth <kbe...@sandia.gov>:
>>> Apologies if this has been answered before. In an effort to ensure
>>> cross-platform consistent results, I need to force some (C++ and
>>> Fortran)
>>> source files to always be built debug. Is there any easy syntax to
>>> do this?
>>>
>>> I build our libraries like this.
>>>
>>> SET(SRCS
>>> ${EXEC_DIR}/AfterStep.f90
>>> ${EXEC_DIR}/ArgCF_Connect.f90
>>> ${EXEC_DIR}/ArgCF_Solve.f90
>>> ...
>>> )
>>>
>>> ADD_LIBRARY(exec ${SRCS})
>>
>> You may set some specific flags on specific sources using something
>> like
>>
>> set_source_files_properties(file1.f90 file2.f90
>> PROPERTIES
>> COMPILE_FLAGS ${CMAKE_FORTRAN_FLAGS_DEBUG})
>>
>> but as far as I understand this does not replace default compile
>> flags but add
>> extra flags for those particular source files...
>>
>> Now if your "to be compiled with debug options" files may be
>> contained in
>> separate libraries, may be you can create a sub-project which
>> contains those
>> and enforce thsi subproject to be "CMAKE_BUILD_TYPE=Debug".
>>
>>
>> Curious to know, Why do you want to "some files" files to always be
>> built debug
>> in the first place?
>
> For example, certain Lapack routines like slamch and dlamch fail
> outright if compiled O2 or higher (don't ask why we build from source
> instead using an optimized library). In our code base, we have
> several routines that O3 generates bad code on so we can only optimize
> to O2 or lower (it's a compiler bug that we could work around by
> rewriting our code but we choose to optimize to a lower level
> instead). In other cases, when debugging a numerical problem in our
> release code base, one of the simplest ways to find the problem is to
> selectively recompile a single library at a time (and main) in debug
> until the problem goes away. This helps us narrow down the source of
> the numerical differences. These are all related to selectively
> compiling something in, say release, while everything else is built
> debug. Or, as in my case, selectively building certain files or
> libraries in debug with everything else in release.
If your issue just boils down to a faulty optimization by GCC you will
probably get along with the COMPILE_FLAGS source or target properties:
CMake appends them to the compiler flags, and GCC assures that the last
one seen on the command line takes effect.
Furthermore, in order to build with the highest possible optimization,
you could look at the differences between, say, -O2 and -O3, and find
out the particular switches that are causing a crash. Finally, enable/
disable them specifically for the affected source files or targets via
the COMPILE_FLAGS properties, so your projects can be built with, e.g.,
-O3 as a whole.
Regards,
Michael
_______________________________________________
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
