On Tue, Nov 4, 2014 at 1:14 PM, David Coppa <dco...@gmail.com> wrote:
> On Tue, Nov 4, 2014 at 1:12 PM, Stuart Henderson <st...@openbsd.org> 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.
--
"If you try a few times and give up, you'll never get there. But if
you keep at it... There's a lot of problems in the world which can
really be solved by applying two or three times the persistence that
other people will."
-- Stewart Nelson
