On Tue, Nov 4, 2014 at 1:18 PM, David Coppa <[email protected]> wrote:
> On Tue, Nov 4, 2014 at 1:14 PM, David Coppa <[email protected]> wrote:
>> On Tue, Nov 4, 2014 at 1:12 PM, Stuart Henderson <[email protected]> wrote:
>>> On 2014/11/03 17:07, Stuart Henderson wrote:
>>>> On 2014/10/21 20:55, Vadim Zhukov wrote:
>>>> > >> This will break packaging of ports installing CMake package files (see
>>>> > >> the FooTargets.cmake and FooTargets-Release.cmake in PLIST files?)
>>>> > >> when DEBUG is specified.
>>>> > >
>>>> > > True, but by using DEBUG you are already drifting from regular
>>>> > > packages; so you can probably manually fix that one when you need it.
>>>> >
>>>> > If there is one such package, yes, not a problem. When you have a few
>>>> > hundreds items of KDE stuff... Yes, I build debug packages regularily
>>>> > - still trying to catch misterious libkdcraw bug, and other problems
>>>> > do arise often, unfortunately.
>>>>
>>>> Discussed online but summarised here for those who weren't there,
>>>> we can set a variable to use in plists, e.g.
>>>>
>>>> MODCMAKE_BUILDTYPE = -release.cmake
>>>>
>>>> and add it to SUBST_VARS (at first I thought of just "-release", but if
>>>> we add the .cmake it makes things easier for "make plist").
>>>>
>>>> mariadb's default is to build with RelWithDebInfo which is....not small.
>>>>
>>>
>>> I just had another thought about this. Forcing "Release" might force some
>>> C optimizer flags that we don't want. I would have suggested diffing build
>>> logs, but ninja...
>>
>> I already took care of this.
>> See patches/patch-Modules_Compiler_*
>
> Right, but some nasty software can add its own...
> Maybe an ag through the unpacked sources could identify the offenders.
Like grepping for
if(${CMAKE_BUILD_TYPE} MATCHES "Something")
and looking for code changing CFLAGS/CXXFLAGS
into the CMakeLists.txt files...
