> > Well, initially 'the_repository' wasn't tightly tied to a single > subsystem and even now I am not sure we could say it's tightly tied to > a single subsystem. Or maybe I don't understand what you mean. > > Do you mean that it's tightly tied because it needs `#define > USE_THE_REPOSITORY_VARIABLE`? > Sorry if I was not clear earlier. I wasn't referring to 'the_repository' being tied, it was about other global variables being tied to a subsystem. What I meant is that the approach of picking a subsystem and removing the `#define USE_THE_REPOSITORY_VARIABLE` is really effective for removing 'the_repository.' It also helps in localizing the global variables from environment.h that are specific to that subsystem, either into the subsystem itself or into struct repository / repo_settings. But let's say if a global variable is common to 2-3 different subsystems, then this approach would not be feasible for that variable. For that, I would require to individually tackle that variable. This is an approach which I mentioned in my proposal. So using these two approaches according to different needs, I can move forward. > But for other global variables it could be possible to define and use > similar macros. This way it might be possible to remove those > variables step by step only in some files. > Yes, I still need to think through how that would align with the approach I mentioned. Defining a single macro like `#define USE_GLOBAL_VARIABLES` is something I can look into. > > So what I can do is, for removing > > `the_repository`, I can follow the approach you mentioned, and for relocating > > the more general global variables, I can use the approach which I > > talked about in the > > proposal. > > > > What do you think? > > If removing `the_repository` is part of your proposal, then yeah, > describing the approach you will use to remove is a good idea. Yes, it is a part of the project but I haven't added this specific approach in the proposal yet and was hence asking if I can. Thanks:)
