`CMakeUserPresets.json` being read before `CMakePresets.json`

Development
1

This is a continuation of the comment in: https://gitlab.kitware.com/cmake/cmake/-/merge_requests/9110#note_1474956

Basically it is weird how the CMakeUserPresets.json is being read before CMakePresets.json, normally you would expect the inverse. From what @kyle.edwards says it’s because it implicitly uses the include directive on the CMakePresets.json.

2

If one file includes another, the includeing file has to be read first to know that another file has to be included. That’s why the read order is the way it is. We simply made CMakeUserPresets.json implicitly include CMakePresets.json in order to take advantage of the existing code.

In principle, the order in which the files are read shouldn’t matter for the purposes of resolving the preset graph. All of the files should be read first, and then the graph should be resolved.

3

I think the thing that confused me when I tried to reverse the order in the override branch was that the include directives are execute after all of the configurePresets, etc. objects? There was something strange happening when I tried to move the snippet:


  if (rootType == RootType::User && readReason == ReadReason::Root) {
    auto cmakePresetsFilename = GetFilename(this->SourceDir);
    if (cmSystemTools::FileExists(cmakePresetsFilename)) {
      if ((result = includeFile(cmakePresetsFilename, RootType::Project,
                                ReadReason::Root, errMsg)) != true) {
        return result;
      }
    }

near the top so that the order of preset definition is from the bottom most include to the top.

4

@kyle.edwards I think I am encountering some issues with this parsing in https://gitlab.kitware.com/cmake/cmake/-/merge_requests/9110#note_1503756. I haven’t debugged this issue to see how and where it fails, but I could use some fresh pair of eyes. That is the last part of the MR that needs to be resolved