Enter custom path to the config file via command line

[minhqdao]

Instead of having the global config file stored in a predetermined system location, users can specify a custom location for the file by using a command option. That allows for having all configurations in a single folder and makes it easier, e.g., to use the global config file in the CI.

Use:

fpm build --config-file config.toml # read file from project root

The documentation will be updated as soon as this PR is approved.

[perazz]

There are a few things I'd like to point out about this PR before I think it's ready to merge:

• I can't find a reference to the "global config file" in the documentation; can you please point me to it? without it, I think it's useless to let the users input an undefined config file
• Why does that belong in the dependency tree? Does it only deal with the dependencies for the local registry? Then, we should not call it "global config file", neither internally nor in the CLI API
• This PR contains most code refactorings, it makes it hard to find the important changes (this had been discussed already during one of our meetings); please submit them as a separate pr
• This PR says there's a config-file option, but the code introduces a global-config flag, what's supposed to be the final one?
• a fpm_global_settings object only appears in a subroutine within the dependency tree module. If in the future this is going to be a global fpm setting structure, it should be stored as such somewhere else (perhaps inside the fpm_cmd* structure?), so its parameters are set from either the cached version, or an external file, or the CLI, instead of passing them through the depednency tree API

[minhqdao]

• I can't find a reference to the "global config file" in the documentation; can you please point me to it? without it, I think it's useless to let the users input an undefined config file

https://fpm.fortran-lang.org/en/spec/manifest.html#global-config-file

• Why does that belong in the dependency tree? Does it only deal with the dependencies for the local registry? Then, we should not call it "global config file", neither internally nor in the CLI API

That's a bit tricky to answer. I agree that it is more of a command option (which it also is) than it is part of the dependency tree. But just as some other members of the dependency tree which seem a bit misplaced, such as verbosity and dep_dir, this seemed like a reasonable place for me to put it if you don't want to rethink the entire current structure. You could argue that the global config file contains information on where to draw dependencies from. However, the global config file isn't meant to exclusively hold registry information.

[minhqdao]

• a fpm_global_settings object only appears in a subroutine within the dependency tree module. If in the future this is going to be a global fpm setting structure, it should be stored as such somewhere else (perhaps inside the fpm_cmd* structure?), so its parameters are set from either the cached version, or an external file, or the CLI, instead of passing them through the depednency tree API

Actually unrelated to fpm_cmd*. We had a similar discussion here.

[minhqdao]

There are a few things I'd like to point out about this PR before I think it's ready to merge:

• I can't find a reference to the "global config file" in the documentation; can you please point me to it? without it, I think it's useless to let the users input an undefined config file
• Why does that belong in the dependency tree? Does it only deal with the dependencies for the local registry? Then, we should not call it "global config file", neither internally nor in the CLI API
• This PR contains most code refactorings, it makes it hard to find the important changes (this had been discussed already during one of our meetings); please submit them as a separate pr
• This PR says there's a config-file option, but the code introduces a global-config flag, what's supposed to be the final one?
• a fpm_global_settings object only appears in a subroutine within the dependency tree module. If in the future this is going to be a global fpm setting structure, it should be stored as such somewhere else (perhaps inside the fpm_cmd* structure?), so its parameters are set from either the cached version, or an external file, or the CLI, instead of passing them through the depednency tree API

The points have been addressed. Let's move on with the reviews. Having this PR in will make it easier to set up some example packages that include, e.g., a local registry.

@arteevraina @henilp105 @perazz

[henilp105]

CI failure is unrelated to this PR, It is due to #1025 .