[PATCH 2 of 2 RFC] config: introduce platform specific sections

Matt Harbison mharbison72 at gmail.com
Thu Mar 26 18:59:24 CDT 2015


On Thu, 26 Mar 2015 10:35:03 -0400, Yuya Nishihara <yuya at tcha.org> wrote:

> On Wed, 25 Mar 2015 21:15:27 -0400, Matt Harbison wrote:
>> On Mon, 23 Mar 2015 16:02:16 -0400, Matt Mackall <mpm at selenic.com>  
>> wrote:
>> > On Fri, 2015-03-20 at 18:36 -0400, Matt Harbison wrote:
>> >> # HG changeset patch
>> >> # User Matt Harbison <matt_harbison at yahoo.com>
>> >> # Date 1426888879 14400
>> >> #      Fri Mar 20 18:01:19 2015 -0400
>> >> # Node ID 636f51ff2cfc9bbd665f1b3bf198d780a2afffe8
>> >> # Parent  6b3aff8a06f1cf7057a9bdcdc5e301dde0801828
>> >> config: introduce platform specific sections
>> >
>> > Please take a peek at Greg's patches where he's proposing using
>> > [foo.bar] for something else. I can't say I'm excited by either
>> > proposal.
>> >
>>
>> Yep, I saw he hadn't ruled that out yet and pinged him on Monday.
>>
>> In the meantime, do you have any alternate ideas for this?  I wasn't  
>> sure
>> how your
>>
>>    new.style =
>>    old.style.path =
>>
>> suggestion would apply to this, since that probably requires knowledge  
>> of
>> what is possible in each section.  ([extensions] for example allows a
>> leading 'hgext.', so it isn't a general split on '.' and compare
>> algorithm.)
>
> As the magic is done at config.parse() layer, how about %if like a C
> preprocessor?
>
>   [systest]
>   %if $platform == 'win32'  # or %ifeq(...,...) ?
>   key = windowsvalue
>   %elif $platform == 'linux'
>   key = linuxvalue
>   %endif
>
> (I don't know if mpm likes it. ;)
>

Interesting thought, thanks.  I'll take a look at it this weekend.

Any thoughts about the form of the $platform part, with an eye toward  
future expansion?  I didn't think about it before (and don't have a use  
for it currently), but it seems like env variables could be checked here  
too.  The %ifeq() makes me wonder if the templater methods can be used  
too, but I don't want to make this tooo complicated.  I just don't want to  
cut future expansion off at the knees (yes, I know the original proposal  
did just that).

--Matt


More information about the Mercurial-devel mailing list