~eschwartz

~eschwartz/foo-test

Last active 8 months ago
View more

Recent activity

Re: [PATCH v2] implement automatic array conversion of even more args a day ago

From Eli Schwartz to ~lattis/muon

On 9/15/21 17:15, Stone Tickle wrote:
> Oops!  Very sorry about that.  The reason I changed it back is because
> only obj_dependency is handled in the output generator.  Since the
> output generator was assuming everything was an obj_dependency, there
> were some pretty strange errors.  I suppose the proper fix for this is
> to handle obj_external_library in output.c.


Indeed, thanks.


> By the way, would there be any difference between link_with and
> dependency in this case?

Re: [PATCH v2] implement automatic array conversion of even more args a day ago

From Eli Schwartz to ~lattis/muon

On 9/8/21 23:05, Eli Schwartz wrote:
> While we are here, take the opportunity to actually check the type of
> the contents, which formerly was just "obj_array containing obj_any".
> 
> I have left alone:
> [...]
> - dependencies, since it needs to handle dependencies,
>   external_libraries, and declare_dependencies, and using obj_dependency
>   at least causes external library failure

In commit 8f9511aeab7eeaa22c6381263185461af15c00b9

"ensure deps is an array of dependencies"

[PATCH] include_directories: accept multiple args 4 days ago

From Eli Schwartz to ~lattis/muon

e.g. include_directories('incdir', 'incdir2') is valid and should
produce two -I paths.
---
 src/functions/default.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/functions/default.c b/src/functions/default.c
index 562de2e..015caf3 100644
--- a/src/functions/default.c
+++ b/src/functions/default.c
@@ -308,7 +308,7 @@ func_find_program(struct workspace *wk, uint32_t _, uint32_t args_node, uint32_t
static bool
func_include_directories(struct workspace *wk, uint32_t _, uint32_t args_node, uint32_t *obj)
{
[message trimmed]

Re: [PATCH v2] implement automatic array conversion of even more args 7 days ago

From Eli Schwartz to ~lattis/muon

On 9/9/21 4:37 PM, Stone Tickle wrote:
> Thank you, this looks good to me.  I really appreciate you taking the
> time to test this on some real projects.  As far as list flattening
> goes, I have been addressing it so far with ad-hoc application of the
> obj_array_foreach_flat, which iterates over the array as if it were
> flattened.  Maybe ARG_TYPE_ARRAY_OF should imply that the array gets
> flattened also.  We could even flatten all arrays passed as arguments,
> but I'm not sure about that imo.


From IRC:


06:37 PM <@dcbaker> Meson flattens arrays for all inputs unless those

[PATCH v2] implement automatic array conversion of even more args 8 days ago

From Eli Schwartz to ~lattis/muon

While we are here, take the opportunity to actually check the type of
the contents, which formerly was just "obj_array containing obj_any".

I have left alone:
- link_with, since it needs to handle both libraries and custom_target
- include_directories, as it does custom type coercion
- dependencies, since it needs to handle dependencies,
  external_libraries, and declare_dependencies, and using obj_dependency
  at least causes external library failure
---
 src/functions/default.c | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/src/functions/default.c b/src/functions/default.c
[message trimmed]

Re: [PATCH] implement automatic array conversion of even more args 8 days ago

From Eli Schwartz to ~lattis/muon

On 9/8/21 10:38 PM, Eli Schwartz wrote:
> On 9/6/21 9:19 PM, Stone Tickle wrote:
>> Thanks for this!  Overall, I think (hope) we can be a little more strict
>> with some of these.  Basically using obj_any means that we have to write
>> some sort of custom type checking logic, so to the extent possible we
>> should let interp_args handle it.  Perhaps the meaning of
>> ARG_TYPE_ARRAY_OF is a little unclear; `ARG_TYPE_ARRAY_OF | obj_string`
>> for instance means this:
>>
>> 'hello' # gets coerced to ['hello']
>>
>> or
>>
>> ['hello', 'there']

Re: [PATCH] implement automatic array conversion of even more args 8 days ago

From Eli Schwartz to ~lattis/muon

On 9/6/21 9:19 PM, Stone Tickle wrote:
> Thanks for this!  Overall, I think (hope) we can be a little more strict
> with some of these.  Basically using obj_any means that we have to write
> some sort of custom type checking logic, so to the extent possible we
> should let interp_args handle it.  Perhaps the meaning of
> ARG_TYPE_ARRAY_OF is a little unclear; `ARG_TYPE_ARRAY_OF | obj_string`
> for instance means this:
> 
> 'hello' # gets coerced to ['hello']
> 
> or
> 
> ['hello', 'there']
> 

Re: list/string handling in meson vs. muon 10 days ago

From Eli Schwartz to ~lattis/muon

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

[PATCH] implement automatic array conversion of even more args 10 days ago

From Eli Schwartz to ~lattis/muon

---
 src/functions/default.c | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/src/functions/default.c b/src/functions/default.c
index 18219d5..26017fe 100644
--- a/src/functions/default.c
+++ b/src/functions/default.c
@@ -87,7 +87,7 @@ func_project(struct workspace *wk, uint32_t _, uint32_t args_node, uint32_t *obj
		kw_version
	};
	struct args_kw akw[] = {
		[kw_default_options] = { "default_options", obj_array },
		[kw_default_options] = { "default_options", ARG_TYPE_ARRAY_OF | obj_any },
[message trimmed]

Re: list/string handling in meson vs. muon 11 days ago

From Eli Schwartz to ~lattis/muon

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.