[Build-common-hackers] flavors: pass flavor-specific flags after DEB_CONFIGURE_EXTRA_FLAGS

[Jonas Smedegaard]

On Sat, Jan 08, 2011 at 06:06:00PM +0000, Emilio Pozuelo Monfort wrote:
>On 08/01/11 16:56, Jonas Smedegaard wrote:
>> On Sat, Jan 08, 2011 at 04:28:14PM +0000, Emilio Pozuelo Monfort 
>> wrote:
>>> On 08/01/11 15:52, Jonas Smedegaard wrote:
>>>> On Sat, Jan 08, 2011 at 03:31:26PM +0000, Emilio Pozuelo Monfort 
>>>> wrote:
>>>>> I'm converting gtk+3.0 now, and I've found a little issue:
>>>>>
>>>>> We build 3 flavors, shared, udeb and static. What I would like to 
>>>>> do is something like
>>>>>
>>>>> DEB_CONFIGURE_EXTRA_FLAGS += --enable-introspection=no
>>>>> DEB_CONFIGURE_FLAGS_shared += --enable-introspection=yes
>>>>> DEB_CONFIGURE_FLAGS_udeb += --disable-some-features
>>>>> DEB_CONFIGURE_FLAGS_static += --enable-static
>>>>>
>>>>> i.e. since most flavors shouldn't build introspection support, I 
>>>>> disable it in EXTRA_FLAGS (which is like "common flags"), and only 
>>>>> enable it in the shared flavor flags.
>>>>
>>>> I believe the proper approach is then to use this:
>>>>
>>>> DEB_CONFIGURE_FLAGS_DEFAULT += --enable-introspection=no
>>>
>>> Hmm, I can't find DEB_CONFIGURE_FLAGS_DEFAULT mentioned anywhere in 
>>> CDBS. Do you mean that I should add support for it in CDBS? Or is it 
>>> expanded and that's why I can't find it?
>>
>> The latter.
>>
>> DEB_CONFIGURE_EXTRA_FLAGS is an old oddity while 
>> DEB_CONFIGURE_FLAGS_* is the new style hopefully aiming at being more 
>> consistently named.  They are unrelated, so it doesn't surprise me 
>> that it doesn't work to use them together.
>
>So it turns out DEB_CONFIGURE_FLAGS_DEFAULT is not currently supported.
>
>Should it be similar to DEB_CONFIGURE_EXTRA_FLAGS? Or be an alternative 
>to DEB_CONFIGURE_FLAGS_$(flavor) as in:
>
>cdbs_configure_flags += $(if
>$(DEB_CONFIGURE_FLAGS_$(cdbs_make_curflavor)),$(DEB_CONFIGURE_FLAGS_$(cdbs_make_curflavor)),$(DEB_CONFIGURE_EXTRA_FLAGS_DEFAULT))
>
>My opinion is that it should affect all flavors. So it should be more like
>
>cdbs_configure_flags += $(DEB_CONFIGURE_FLAGS_DEFAULT)
>cdbs_configure_flags += $(if
>$(cdbs_make_flavors),$(DEB_CONFIGURE_FLAGS_$(cdbs_make_curflavor)),)
>
>Would we also deprecate DEB_CONFIGURE_EXTRA_FLAGS in favor of
>DEB_CONFIGURE_FLAGS_DEFAULT ?
>
>Also what's the intended purpose of DEB_CONFIGURE_USER_FLAGS ?

DEB_CONFIGURE_EXTRA_FLAGS and DEB_CONFIGURE_USER_FLAGS are old vars. 
Their names are non-intuitive.  But they cannot easily be dropped or 
change behaviour, as lots of users depend on them.

DEB_CONFIGURE_FLAGS_{ALL,DEFAULT,$(pkg)} are new vars for the same. 
Their names and behaviour are (supposed to be) intuitive and consistent 
with thos of snippets.  But they might not all work properly yet.  That 
is however not regressions so less important: noone rely on them yet.

Then there's the recently realized mess of expanding with both $(pkg) 
and $(flavor).  This really should be fixed properly at the core, rather 
than tweaking on top of the generic expansion routine.


Therefore, I dislike your proposed patch.

Short-term I suggest you try conditionally overriding 
DEB_CONFIGURE_EXTRA_FLAGS or DEB_CONFIGURE_USER_FLAGS locally in your 
package based on $(cdbs_curflavor).

Long-term (but hopefully soon reached!) I would appreciate help getting 
$(cdbs_curpkg) and $(cdbs_curflavor) resolvable independently of each 
other, and then _afterwards_ fix any remaining flaws on top of that.

Currently the core vars are resolved like this (expressed as PCRE):

   curflavor: .*/([^/]+)
   curpkg:    .*/([^/]+)

I.e. both resolve to part of string after last "/" if "/" exist at all.

My idea at the moment is to have them resolve like this:

   curflavor ~= .*/FLAVOR/([^/]+)
   curpkg    ~= .*(?<!FLAVOR)/([^/]+)

I.e. distinguish if stripped part of string ends in "/FLAVOR/" or not.

How does all that sound?


  - Jonas

-- 
  * Jonas Smedegaard - idealist & Internet-arkitekt
  * Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/build-common-hackers/attachments/20110108/4cd344a8/attachment-0001.pgp>