Cross-platform library: how to organize project?

Question

Our company develops and sells a cross-platform C++ library. We distribute binary only versions for Windows, Mac OS X, Linux, iOS, Android, etc. The only source code the customers get is the header files with the class interfaces. Our IDE is Visual Studio; we're very glad it now supports cross-compilation out-of-the-box (clang! remote control of a Mac with XCode! Ability to call older versions of the compiler! Makes our lives much easier). We try to build all the versions at the same time on the same build machine (which calls out to a Mac to do the iOS and Mac OS X ports). Most customers are on Windows and just get the libraries for recent Visual C++, but some customers get the works.

The code itself is the same between platforms.

However, not all of our customers are on the latest version of Visual Studio -- some of them are using versions as far back as 2005. While we are trying to encourage them to move to a newer version, we still have to support the old ones if they find a bug.

This leads to a proliferation of product configurations: (Debug/Release) * (Static library/Shared Library) * (Platform) * (x86/x64/ARM) * (Compiler version)

most of which are very similar to each other, but with some differences.

I was studying MSBuild and playing around with the .vcxproj file but it still seems extremely complicated (and Visual Studio chokes on any .vcxproj with anything more than a bare minimum of tweaks).

The way we used to deal with this was to manually tweak the project each time we were doing a new build. That is obviously unsustainable.

I was assigned to bring the project up-to-date, and I initially created a bunch of new configurations, corresponding to that absurd cross product I mentioned above. I think that makes for 40 configurations. Ugh. But aside from the management headache, I didn't always make the necessary project settings changes when copying from (say) x86 to x64. So some of the new configurations didn't build when I did a batch build.

In order to stop this happening again, I created a bunch of new user macros in the project file (probably should have been in the .props file referenced in the

<ImportGroup Condition="'$(Configuration)|$(Platform)'=='Release-2013|Win32'"
 Label="PropertySheets">
    <Import Project="$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props"
     Condition="exists('$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props')"
     Label="LocalAppDataPlatform" />
    <Import Project="$(VCTargetsPath)Microsoft.CPP.UpgradeFromVC60.props" />  
</ImportGroup>

I guess) and made sure that all the project configurations were the same and that the changes between each of them were just made in the user macros. But that's getting unwieldy too, and pulling down a menu of 40 things to select the right thing to build, plus then having to go into the right folder and pick out the relevant files, also seems error prone.

So my question is: How can I make this more automatic and not require so much thought? Do people creating a cross-platform library really work with 40+ configurations in their project? How are some ways people handle this in real life -- or at least set things up so they don't make so many mistakes?

Answer 1

In a past project of mine, I had to deal with a very large amount of configurations, just like you. In the end, I dropped VisualStudio's IDE configuration management in favor of a scripted one (Premake in my case). This lets me generate a solution with just the configurations I want to use (or even all at the same time), just by letting the scripted system cross-combining the different options for me. For instance, I can tell "build me a solution for VS2013 x64, VS2013 x86, VS2015 x64 and Linux x64, for both 'debug' and 'release'".

It's not as nice as having it all in the IDE, but lets me have a fine control of every option without going insane every time I have to change a setting.