%cmake macro

Jakub Bogusz qboosh at pld-linux.org
Thu Feb 3 18:10:29 CET 2011


On Tue, Feb 01, 2011 at 07:51:42PM +0100, Kacper Kornet wrote:
> I think that current %cmake macro is broken. For example soprano.spec is build
> with options: -O2 ... -O3, which is effectively -O3. As far as I understand the
> preferred option would be -O2, 
> 
> In cmake the options are build form two variables as following as:
> 
> CMAKE_C_FLAGS CMAKE_C_FLAGS_<Buildtype>. 
> 
> while %cmake defines CMAKE_C_FLAGS and uses
> Builtype = RELEASE. 
> 
> So I think there are the following possibilities:
> 
> 
> 1. Define CMAKE_C_FLAGS_RELEASE in %cmake
> 
> Flaws:
> A package can define that variable internally in such a way that  it has
> precedence.  For example packages from kde4 do it.
> 
> 
> 2. Change the build type we use to None. Then only CMAKE_C_FLAGS will be used
> 
> Flaws:
> Same as above. But I don't know if any package redefines that variable
> unconditionally.

Some packages set build type to some value (mostly Release) if it's not
specified/None.

> Also if a package uses some special options in release flags, i.e. to avoid
> debug output, we would need to include them in out definition of CMAKE_C_FLAGS
> for this package.
> 
> 
> 3. Use or own build type like: cmake
> -DCMAKE_C_FLAGS_PLD=""${CFLAGS:-%{rpmcflags}}"

+ "-DNDEBUG" I think

> Flaws:
> If a package uses some special options in release flags, i.e. to avoid debug
> output, we would need to put them into our flags. 
> 
> 
> I can implement the third solution. But first I am waiting for any objections
> or better ideas.

Needs some testing probably.

BTW, I mentioned this cmake issue on -devel-? list some months ago.


-- 
Jakub Bogusz    http://qboosh.pl/


More information about the pld-devel-en mailing list