[CMake] Problem with set_target_properties on mixed-source library

Alan W. Irwin irwin at beluga.phys.uvic.ca
Mon Sep 29 11:29:23 EDT 2008


On 2008-09-29 16:00+0200 Martin Apel wrote:

> Hi all,
>
> I have a library consisting of multiple sources from Fortran and C, e.g.
> file1.f, file2.f, file3.c.
> I want to generate this library in two different versions, where in one
> of those versions the Fortran files are compiled with different options,
> in my case with -ipo.
> That means:
>    libv1.a   = file1.o file2.o file3.o               compiled without
> ipo-options
>    libv2.a   = file1.o file2.o with ipo-option, file3.o without ipo-option
>
> I tried to use set_target_properties on libv2 to set the ipo-flag, but
> this also sets this option for the C files, which the compiler does not
> understand.
> I also cannot use set_source_properties, because the same source files
> will be compiled with different options.
>

Hi Martin:

The scenario I am thinking about is the one where you set source properties
with non-ipo flag, build your non-ipo library, then set the source
properties _again_ using ipo flag, and build your ipo library. Setting a new
compilation flag using set_source_properties should (in an ideal world) mean
that the source gets recompiled, but that is just my opinion and the CMake
developers may be up against practical constraints that don't allow this or
they may have intended recompilation to take place whenever a compile flag
is changed, but there may be a bug in the implementation for Fortran or in
general.

To further the discussion and be absolutely sure about the behaviour you are
reporting, I suggest you make the simplest-possible self-contained example
of the issue consisting of a CMakeLists.txt file and two "hello world1" and
"hello-world2" source files where the first one (only) should have different
compiler flags for two distinct libraries that you build. Also, to rule out
a Fortran specific bug, the two different files should be C.  Then you
should be able to show (using make VERBOSE=1) exactly what flags are used
for each build and indeed whether the object is rebuilt (like I think it
should be in an ideal world) because of the changed compile flags set with
source properties.

To actually work around your problem rather than boiling it down to a
simplest case that would potentially convince the CMake developers there is
a bug or misfeature here, you could simply copy your source files (with
CMake so you only have to maintain one set of source files) and proceed
independently for the two libraries with differently named source files when
compiled with different flags.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________


More information about the CMake mailing list