%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