meson: Division of labor between `coredata` and `environment` is no longer clear
Originally coredata
was supposed to be for data that was persisted, and environment
was supposed to be for data that wasn’t. But at this point I think much of the intent has rotted away and we basically have to big, entangled balls of arbitrary functionality.
Let’s take some time to re-envision how we want things to work, and how we might divide (or not divide!) the division of labor.
About this issue
- Original URL
- State: open
- Created 4 years ago
- Reactions: 1
- Comments: 16 (16 by maintainers)
I am not working on meson long enough to know how things were originally meant to be divided (and without having touched most of the code in both of them), so I can only talk about what I would expect
Environment
andCoreData
to be.First of all, I have found it always strange that the compiler detection logic is in
Environment
. For me, it would make much more sense to move this to a separate class incompilers
. Also, why are functions likeget_clang_compiler_defines
inenvironment
and not in the relevantcompilers.mixins
?Then, why is there option handling in both
Environment
andCoreData
? I would suggest splitting this into a newAllMesonOptions
(yes, I am not good with names) class (that is also serialized likeCoreData
).So, in pseudocode, this would result in:
Here’s a list of things that are supposed to be computed only once (without a wipe):
And the things that need to be recomputed on reconfigure
The thing is, all of that stuff needs to be serialized. I’m not really sure what Environment should be providing. I thinkj @mensinda’s proposal is a good one, basically turning coredata into a composed class instead of two mega classes. Along with this, I think it might be good to have some options that the compilers generate at the class level instead of the instance level, like
c_args
andc_link_args
since we need those before the class is actually instantiated.