Allowing += to be used with value from hash

[mitchgrout]

Consider the following fragment:

cfg = { 'sources': [], 'includes': [] }
cfg['sources'] += files('foo', 'bar', 'baz')
cfg['includes'] += include_directories('inc')

Evaluating this will provide the following error

meson.build:2:0: ERROR: Plusassignment target must be an id.
cfg['sources'] += files('foo', 'bar', 'baz')
^

Is this intentional, or an oversight in the grammar/interpreter? It provides a nice way to represent data clumps (e.g. variables that do not make sense without each other), and is otherwise expressible with the more awkward

cfg = { 'sources': cfg['sources'] + files('foo', 'bar', 'baz'), 'includes': cfg['includes'] }

My suspicion is that the grammar specifies that += is only allowed on variable-ish things, and var[subscript] is not recognized as variable-ish. Could this be changed?

[mitchgrout]

Addendum, this is also currently not possible:

cfg['extra'] = 42

with a similar message:

meson.build:2:0: ERROR: Assignment target must be an id.
cfg['extra'] = 42
^

[QuLogic]

Dictionaries are immutable, so the assignment in your reply can't work. Arrays are also immutable, and adding to them only creates a new object. So these two things together means += also will not work with dictionaries, even if the values are arrays.

[xclaesse]

Note that you can do cfg += {'sources': cfg['sources'] + files('foo', 'bar', 'baz')}.

[mitchgrout]

I can understand a rationale for mutability there; it's a lot easier to treat structures as value types rather than reference types, and makes understanding simpler. I would then argue that there would be no reason as to why the following could not be defined:

cfg = { 'sources': [] }
cfg['sources'] += files('foo')
# is equivalent to
cfg = { 'sources': cfg['sources'] + files('foo') }

as it preserves the immutability in the same way as

sources = []
sources += files('foo')
# is equivalent to 
sources = sources + files('foo')

[mitchgrout]

While I also accept that manually expanding it would work in this case, it does not scale particularly nicely. Consider the following:

cfgs = { 
  'module-1': { 'sources': [], 'includes': [] },
  ...
  'module-N': { 'sources': [], 'includes': [] },
}

# Append a source to 'module-1'
# Proposed way:
cfgs['module-1']['sources'] += files(...)

# Current way:
cfgs  += { 'module-1': { 'sources': cfgs['module-1']['sources'] + files(...), 'includes': cfgs['module-1']['includes' } }

I would argue that a little syntactic sugar would go a long way here. This is not a contrived example either; I currently need to structure my project using a hash similar to the above due to needing to provide a large set of arguments to my build targets that would otherwise be unnecessarily duplicated. I also need to tweak source/include lists depending on build configuration that is otherwise not easily expressible.

[eli-schwartz]

Are there places where you could convert those arguments into declare_dependency() holders (yes those can handle sources too, and even depend on other declared dependencies)? You'd end up with a somewhat nested internal structure but it should in theory all work out in the end.

[mitchgrout]

The project structure is pretty convoluted for legacy reasons. The gist of it is:

1. When building my target, I provide all sources and include paths to an executable() call; there are no intermediate lib structures. I can do this with a dep without issue, and is indeed how I manage this portion
2. When building for tests, I instead need to build each module as a library() so that I can test it against test-double libraries for the rest of the system
   a. This might also involve extracting a single object from the library under test, which would need .extract_objects(exact-path), which is not recoverable using a dep alone

I can see how using a utility dep would make my life simpler here, but unfortunately it cannot fit my entire niche.