Can source code, automake and configure files for multiple OS co-exist in one Git branch

Question

I am working on an open source project that should be compiled for multiple operating systems including Ubuntu and Windows.

I am working on how to structure the Git repositories and branches for this project.

My question is can the same code with different configuration files coexist in one Git branch? or should there be a separate branch for each operating system because of the autogenerated files generated by autogen, configure and make.

What is the industry practice for C++ projects that are OS agnostic.

• Doc Brown: This is essentially the same questions for browser plugins and different target browsers, and the answer is pretty much the same as it should be here: have a single branch with two distinct build steps for each target platform.
• Nicol Bolas: The closest to "industry practice" you'll find for this is "Use CMake".
• Bart van Ingen Schenau: Yes, you should have the configuration files for all platforms in the same branch. Keep in mind that the output from autogen, configure, make, etc. should not be stored in git at all. It contains information that applies only to your machine and will be different for other users.
• txtechhelp: industry practice for C++ projects that are OS agnostic ... #ifdef? ;)

Answer 1

I suggest you look at the build system for existing libraries like Boost or my own Stroika.

These are two open source libraries with relatively simple branch structures (in git). They are both cross platform.

In both cases, there is no connection between branching and platforms. Generally - you will want to use a directory hierarchy with your source code so its logically organized. And if you have some platform-specific code, often libraries will segregate that into a platform specific folder (e.g. Library/Sources/Stroika/Foundation/Execution/Platform/POSIX versus Library/Sources/Stroika/Foundation/Execution/Platform/Windows)

A time where you would want to use branching in a way that was related to platform, is if you wanted to add experimental code to support a new platform and didn't want that to interfere with other work. But once the new 'feature'/platform is working, it generally gets integrated back to the main branch.

What Stroika does for the issue you are saying - about automake - is that its build system (makefiles) create a folder called "Configurations" which contains essentially the input for the automake process. Then the build makefiles create folders IntermediateFiles/{CONFIGNAME} for each configuration, and Builds/{CONFIGNAME} for each configuration. This is not checked in (so has nothing to do with source control). It's just artifacts that are part of the build process.

• amon: While I think this answer gets the point across – don't branch per platform, configure per platform – I'm not sure whether Stroika is the best example: it's build system looks quite complex even for C++ standards.
• Lewis Pringle: I am biased about the complexity of stroikas build system but I can assure you I strive for simplicity and flexability. At its heart you do configure and then make. That's pretty traditional in the c programming world. And as that basic process is pretty widely used I'm not sure it's a bad example.@amon
• Lewis Pringle: One of the banes of the c++ world is there is no good answer here. Which is why there are hundreds of different answers. If you take the top ten most popular c++ libraries you'll probably find 8 different build approaches. But having a configure script followed by a makefile is probably still most common.@amon