Namespaces for variables

[bruchar1]

Since my project is a monorepo, it becomes bigger and bigger, and the number of variables is constantly increasing... I'm wondering if a notion of namespace (or object, not sure how to name it) would be useful. Something like:

mylib = namespace()  # optional arg could be used to initialize variables, if wanted
mylib.name = 'mylib'
mylib.src = files(...)
mylib.lib = library(mylib.name, mylib.src, ...)

with mylib
    other_lib = library(..., link_with: .lib, ...)
    .new_var = 'some value'
endwith

What do you think about this idea?

[eli-schwartz]

What's the advantage of this over, say, local variables that are only in scope in the current meson.build file?

My assumption is that what you're after here is the ability to have a block of code where you can set variables and have them be specific to that block. That is how the example seems to be getting used.

[bruchar1]

What's the advantage of this over, say, local variables that are only in scope in the current meson.build file?

The advantage is that those variables are still accessible from other build files. For instance, I often have my lib defined in one build file, and the related tests defined in a different build file. But this is an advantage only if the names can be shortened inside a block, otherwise using prefixes in variables names would be the same.

In fact, locally scoped variable was another option I thought about. And a third option would be variable local to current build files and subdirs. What do you think? Would local variables be a better option? But in another hand, would it really change something, as I can just use a convention for local variable names, and simply override its value when I need to? Maybe for memory consumption, but I doubt it would really make a difference. Or it could simply be a delete(variable) function...

[eli-schwartz]

There has been a non-trivial amount of discussion about local variables by people who want them. I think they're definitely useful regardless of any other features -- "just use a convention" is easy to mess up and then your build definitions leak and corrupt other parts of your build.

True, they aren't necessarily the best answer for every case.

I will confess to some slight curiosity at the idea of namespaced library definition variables that are also wanted in other build files for use in tests. e.g. why do you need to reuse the list of input files?

[bruchar1]

Probably not the list of source files... But the library object, the internal dependency of this library, and array of compile args... There are many variables that may be reused. One usecase is that sometimes, we link test with objects, because we need to test functions that are not exposed in the shared library interface (I'm not saying this is a good thing, but this is like that for now...) In that case, we need to share most or the arguments passed to the library function.

[eli-schwartz]

I wonder how far you can get today using testdep_foo = declare_dependency() for this?