[104377] trunk/dports/_resources/port1.0/group/cmake-1.0.tcl

[Sean Farley]

Joshua Root writes:

>> Revision: 104377
>>           https://trac.macports.org/changeset/104377
>> Author:   sean at macports.org
>> Date:     2013-03-23 20:10:41 -0700 (Sat, 23 Mar 2013)
>> Log Message:
>> -----------
>> cmake-1.0.tcl: add extra logic to protect against bad configure option
>> 
>> Modified Paths:
>> --------------
>>     trunk/dports/_resources/port1.0/group/cmake-1.0.tcl
>> 
>> Modified: trunk/dports/_resources/port1.0/group/cmake-1.0.tcl
>> ===================================================================
>> --- trunk/dports/_resources/port1.0/group/cmake-1.0.tcl	2013-03-24 01:57:12 UTC (rev 104376)
>> +++ trunk/dports/_resources/port1.0/group/cmake-1.0.tcl	2013-03-24 03:10:41 UTC (rev 104377)
>> @@ -88,3 +88,9 @@
>>      configure.args-delete   -DCMAKE_BUILD_TYPE=Release
>>      configure.args-append   -DCMAKE_BUILD_TYPE=debugFull
>>  }
>> +
>> +# cmake doesn't like --enable-debug, so in case a portfile sets
>> +# --enable-debug (regardless of variant) we remove it
>> +if {[string first "--enable-debug" ${configure.args}] > -1} {
>> +    configure.args-delete     --enable-debug
>> +}
>
> Under what circumstances is this configure arg going to be present
> before the cmake portgroup is included? And would it not make more sense
> to not add it in the first place?

Ah, right. I convinced myself that this needed to be outside the debug
variant but for this commit, I should I have put it inside the variant
(if at all). My plan was to abstract all the debug variants into a port
group so there was one generic template. If that port group exists, then
the cmake port group could just import that instead of redefining its
own debug variant.