Description

Fixes #3116

Prior to this change, if the primary config file was missing, it was created, but instead of the defaults, the current config settings were written. This included the local dosbox.conf if it existed and any extra configs loaded with the --conf CLI option on top of the actual defaults.

This change ensures that if we create the primary config on startup, it always contains the defaults and nothing else.

Manual testing

If the primary config does NOT exist in the user folder

Test 1

• Started Staging in a directory that has a local config that set cycles to 6666.
• Confirmed the primary config was created with the defaults
• Confirmed "Created primary config file" comes before "Loaded local config file 'dosbox.conf'" in the logs.

Test 2

• Started Staging in the same directory with --nolocalconf --conf dosbox.conf.
• Confirmed the primary config was created with the defaults.
• Confirmed "Created primary config file" comes before "Loaded custom config file 'dosbox.conf'" in the logs.

Test 3

• Started Staging with --machine hercules --set cycles=6666.
• Confirmed the primary config was created with the defaults.

Test 4

• Confirmed the primary config is not created when the --noprimaryconf option is present, regardless of the presence of the local config or any other CLI options.

Test 5

• Confirmed the primary config is not created when launching Staging in portable mode (dosbox-staging.conf exists in the executable directory).

If the primary config DOES exist in the user folder

Confirmed that it never gets recreated or overwritten in any of the above test cases.

Checklist

Please tick the items as you have addressed them. Don't remove items; leave the ones that are not applicable unchecked.

I have:

• followed the project's contributing guidelines and code of conduct.
• performed a self-review of my code.
• commented on the particularly hard-to-understand areas of my code.
• split my work into well-defined, bisectable commits, and I named my commits well.
• applied the appropriate labels (bug, enhancement, refactoring, documentation, etc.)
• checked that all my commits can be built.
• confirmed that my code does not cause performance regressions (e.g., by running the Quake benchmark).
• added unit tests where applicable to prove the correctness of my code and to avoid future regressions.
• made corresponding changes to the documentation or the website according to the documentation guidelines.
• locally verified my website or documentation changes.