Config files best practices

I have been having a debate with my co-worker about the best way to manage config files for multiple environments (mainly production vs. development) and was looking for some outside opinions since he is mainly a web developer and I am a less experienced programmer. The overall problem as stated is this:
We have several small, in-house Qt applications with hardcoded configuration variables (database credentials, file paths, etc.) that I am planning to extract to XML files that the applications will read. Apart from it generally just being good practice not to hardcode these things, I would like to make for easy switching between development/testing and production settings, or any other environment we may need in the future.

My co-worker's thought: A separate dummy config file for each environment (e.g., config.xml.production, config.xml.dev) and it is up to the developer to change the name of the file they want to config.xml, which is the file that the application looks for. I don't like this because I think it invites more user error and I don't want to have to deal with renaming files all the time.

My thought: Either have one config.xml file with different nodes for different environments or a different config file for each environment, and then have a global variable in the application that decides which node/file to use (to be set by the developer as needed). My co-worker doesn't like this because he thinks that if we want to add more different environments it will be a hassle and that the config file selection shouldn't be within the application itself.

I can see both sides of the argument, what I'm wondering is: Is there a best practice on this for Qt applications in particular? Are we both totally way off base in our approach and why? I'm open to any and all thoughts. There is far more collective experience on this forum than there is between my co-worker and myself.

What about passing the config file to use as a command line argument/parameter, i.e. --config=prod.xml or -p (for prod) -d (for dev), etc.

That wouldn't work so well for us as the applications are pretty much never called via the command line. The users of the applications are general retail employees so they click on the .exe file to run it, and when in development I build and run them in Qt Creator.

I was thinking more along the lines of desktop icons that passed the appropriate command line arguments, i.e. "Foo Prod", "Foo Develop", etc. but if that doesn't work for you, then obviously it's not a good choice... :)

Good luck!

Perhaps you could use a QSettings INI-type file to store your environment flag. The app looks for the file (and flag entry) at startup, and if it finds it, it uses that mode. Otherwise, it goes to the default mode (production, presumably). You'll only need the QSettings file on your development / testing machine, not on the machines deployed to users.

By the way, a year or two ago I posted code here that provides a QSettings interface to XML files. You might find it easier to use for your user-side XML config files.

Quote:

---

Originally Posted by ce_nort

That wouldn't work so well for us as the applications are pretty much never called via the command line. The users of the applications are general retail employees so they click on the .exe file to run it, and when in development I build and run them in Qt Creator.

---

That wouldn't be a problem as far as I can tell.

If the application is started without arguments, it just uses the default path or default file name.

If you run in QtCreator you can easily pass arguments as part of the run settings.

Another option is to use an environment variable or even have both options, one overriding the other if both are present.

Cheers,
_

Sounds like there are a few good options out there! Thanks for the ideas. I'll look into them and decide what will work best for us, they all sound like a potential improvement upon the approaches that we came up with.