~lattis/muon

5 2

list/string handling in meson vs. muon

Details
Message ID
<7166b69f-eca0-2515-dc3e-4b0770b6e0c9@archlinux.org>
DKIM signature
pass
Download raw message
Experimenting with trying to build projects using muon, I have quickly
discovered that most projects I tried are failing quite invasively, due
to muon insisting that it was given a string when a list is required.

e.g. c_args, dependencies

In meson.py, this is allowed and perfectly okay, and e.g.

c_args: '-DFOO',

is wrapped in a one-element list for interpretation, as though it said

c_args: ['-DFOO'],


It is pretty common to rely on precisely that in many meson.build files,
and should probably be allowed.

-- 
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User
Details
Message ID
<20210905161050.rhkocbokmh2guoqd@hostomei>
In-Reply-To
<7166b69f-eca0-2515-dc3e-4b0770b6e0c9@archlinux.org> (view parent)
DKIM signature
pass
Download raw message
> In meson.py, this is allowed and perfectly okay, and e.g.
>
> c_args: '-DFOO',
>
> is wrapped in a one-element list for interpretation, as though it said
>
> c_args: ['-DFOO'],

Personally, I think the explicit array form is clearer.  I also assumed
that the implicit form was uncommon, since there are not many cases
where I want to use the sources keyword with a single element, for
instance.  I thought by making the array form mandatory, muon could help
improve the clarity of build files by removing magic coercions.

Unfortunately, it seems that the implicit form is indeed rather common.
I have been running into it a lot while porting meson's test suite over
to muon.  I have a solution in mind, and may go ahead and implement it
in the next few days.

Stone
Details
Message ID
<20210905195139.7vy4uore4uv5jk5u@hostomei>
In-Reply-To
<7166b69f-eca0-2515-dc3e-4b0770b6e0c9@archlinux.org> (view parent)
DKIM signature
pass
Download raw message
If you check my most recent commit (bd76e3b7), I have implemented my
idea.  All you do is or the type with the new constant
ARG_TYPE_ARRAY_OF in the args_norm / args_kw structures type field.
This will get you typechecking of every element in the array as well as
automatic coercion of single-elements into arrays.  I have only applied
updates to types of the target creation functions so far.

Stone
Details
Message ID
<6f4fb952-331b-3832-cfe6-c5d3a10bed88@archlinux.org>
In-Reply-To
<20210905161050.rhkocbokmh2guoqd@hostomei> (view parent)
DKIM signature
pass
Download raw message
On 9/5/21 12:13 PM, Stone Tickle wrote:
>> In meson.py, this is allowed and perfectly okay, and e.g.
>>
>> c_args: '-DFOO',
>>
>> is wrapped in a one-element list for interpretation, as though it said
>>
>> c_args: ['-DFOO'],
> 
> Personally, I think the explicit array form is clearer.  I also assumed
> that the implicit form was uncommon, since there are not many cases
> where I want to use the sources keyword with a single element, for
> instance.  I thought by making the array form mandatory, muon could help
> improve the clarity of build files by removing magic coercions.
> 
> Unfortunately, it seems that the implicit form is indeed rather common.
> I have been running into it a lot while porting meson's test suite over
> to muon.  I have a solution in mind, and may go ahead and implement it
> in the next few days.


Thanks, it seems to work (and I have successfully annotated other
function arguments with your solution).

For what it's worth, I seem to recall back in the day being rather
surprised this worked, too... but yeah, it's too common. I guess you
could log a warning if you want? idk.

By the way, the additional type checking muon does is already coming in
handy. I have done quick tests on configuring lots subproject wrap in
the wrapdb in a for loop, and while many fail due to not yet implemented
stuff  (pkgconfig module, version kwarg on library/declare_dependency) a
couple have failed due to options of type boolean which have a default
string value instead of boolean.

So, I will fix that because it's plainly wrong. (And I am a meson
developer and wrapdb maintainer so I have that ability. :D)

This has actually been mentioned on the meson IRC channel as something
we're not sure why it works and is probably a bad legacy design creeping
through. :(


-- 
Eli Schwartz
Bug Wrangler and Trusted User
Details
Message ID
<20210906141753.emdjzmescojakhvg@hostomei>
In-Reply-To
<6f4fb952-331b-3832-cfe6-c5d3a10bed88@archlinux.org> (view parent)
DKIM signature
pass
Download raw message
> Thanks, it seems to work (and I have successfully annotated other
> function arguments with your solution).

Great, please send a patch :)

> By the way, the additional type checking muon does is already coming in
> handy.  I have done quick tests on configuring lots subproject wrap in
> the wrapdb in a for loop, and while many fail due to not yet implemented
> stuff  (pkgconfig module, version kwarg on library/declare_dependency) a
> couple have failed due to options of type boolean which have a default
> string value instead of boolean.

Awesome, I'm glad to hear that!

> This has actually been mentioned on the meson IRC channel as something
> we're not sure why it works and is probably a bad legacy design
> creeping through. :(

I have noticed a few other weird type coercions, for instance often
empty array, empty string, and null (omitted) argument values have the
same result under meson.  I think this is probably python semantics
leaking through, but overall I think meson has done a good job of hiding
its python implementation.

Stone
Details
Message ID
<c26fc928-da21-db9c-0115-a69f1af0e8b8@archlinux.org>
In-Reply-To
<20210906141753.emdjzmescojakhvg@hostomei> (view parent)
DKIM signature
pass
Download raw message
On 9/6/21 10:17 AM, Stone Tickle wrote:
>> Thanks, it seems to work (and I have successfully annotated other
>> function arguments with your solution).
> 
> Great, please send a patch :)


Sent. :)


>> By the way, the additional type checking muon does is already coming in
>> handy.  I have done quick tests on configuring lots subproject wrap in
>> the wrapdb in a for loop, and while many fail due to not yet implemented
>> stuff  (pkgconfig module, version kwarg on library/declare_dependency) a
>> couple have failed due to options of type boolean which have a default
>> string value instead of boolean.
> 
> Awesome, I'm glad to hear that!
> 
>> This has actually been mentioned on the meson IRC channel as something
>> we're not sure why it works and is probably a bad legacy design
>> creeping through. :(
> 
> I have noticed a few other weird type coercions, for instance often
> empty array, empty string, and null (omitted) argument values have the
> same result under meson.  I think this is probably python semantics
> leaking through, but overall I think meson has done a good job of hiding
> its python implementation.


Yes, I seem to recall we do have a bit of this. Because truthiness
checks in python consider them all false. :(

This should be getting better as time goes by, though. Back in the day,
getting kwargs was a bit of a free-for-all and open coded, IIRC.
Eventually, meson got @permittedKwargs which let it hard error on
invalid arguments to a function in a consistent manner. Now, we're
trying to get everything on to @typed_kwargs and @typed_pos_args which
both validate the names of arguments passed, and check what object types
they are and throw errors on mismatch.

This is (unlike allowing single objects/strings to be coerced to arrays)
an acknowledged bug to be fixed and any meson.build relying on it is
just plain buggy.


-- 
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User
Reply to thread Export thread (mbox)