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)

Most upvoted comments

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 and CoreData 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 in compilers. Also, why are functions like get_clang_compiler_defines in environment and not in the relevant compilers.mixins?

Then, why is there option handling in both Environment and CoreData? I would suggest splitting this into a new AllMesonOptions (yes, I am not good with names) class (that is also serialized like CoreData).

So, in pseudocode, this would result in:

class Environment:
    def __init__(self):
        self.coredata  = CoreData()         # pretty much the same, but without the meson options
        self.options   = AllMesonOptions()  # handles all meson options (also from native and cros files)
        self.compilers = Compilers()        # compiler detection (and storage) from Environment and CoreData

        # handle cross/native files + some general stuff already in Environment

Here’s a list of things that are supposed to be computed only once (without a wipe):

  • machine files
  • environment variables
  • compilers/linkers
  • host/build machine information

And the things that need to be recomputed on reconfigure

  • dependencies (if --reconfigure is given)
  • cli options (if cli options changed)

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 and c_link_args since we need those before the class is actually instantiated.