More code shuffling...

| 2 Comments

The CVS to SVN code migration is going well. As recommended by a commenter I've switched from using a script to pull my tools libraries from their repository into The Server Framework examples build tree to using svn:externals. This works nicely and plays well with branches and tags (as long as you remember to update the svn:externals definition on your branch or in your tag so that it points to the correspondingly tagged version of your externals (but this would have been the same if I were using a script). Using externals isn't perfect mind you; although the externals are automatically processed when you do updates and checkouts they're not when you do commits; which seems a little strange and broken to me. I would prefer that if a file were changed in a directory which was pulled into the tree via an external that it's listed and could be committed when I commit the root of the tree. As it is the externals are ignored. Of course TortoiseSVN shows me that there's a file that's changed in the external tree but I have to go there and commit it from the root of its external tree... Ah well, at least I have update and checkout automation which is more than I have with scripts.

Since I'm using the time before the Christmas break to clean up my build process for next year and since the library rationalisation changes that I mentioned involve lots of changes to my solution files and since I've finally ditched VC6 as a supported platform I figured that it was finally the ideal time to write my solution and project file generating tool. All of my examples, and, indeed, libraries, build for all of our supported compilers. In the past quite a lot of the effort in doing a release of The Server Framework has been keeping these solutions and projects in sync with each other and updated for all changes. Take this recent library change for example. Suddenly I have 4 solutions per example that need to be edited to remove the "C++Tools" library. Having a build server which builds all of the examples is one step in making this less painful (at least the build server will remind me of the examples that haven't been updated as they'll fail to build) but it's still a painful process to have to edit all of these solutions; it's duplication at its worst. Luckily the Visual Studio solution file and project format hasn't changed much since the first release of VS.Net and whilst I could, probably, hack around with clever XML transforms (at least for the project files) I decided to write some C++ to take a 'compiler independent' form of solution and project files and build the files for each specific compiler version. Yesterday I wrote the solution file processing code and I can now generate solution files for VS 2002 through to VS 2008 from a single XML file. What's more my custom file format allows for including extra XML files that might house common projects that are used by more than one solution. The result is that the individual example solutions contain only the details that are specific to the example and the common library dependencies are declared once in a common file. This morning I tested the system by updating one of my packs of server examples to the latest library dependency format; 4 compilers, 15 different examples, all updated by removing one line from the 'common dependencies' file and regenerating the solution files. Nice!

Now I need to sort out the project file generation; this is more complex. Ideally I want to remove the duplication so that I have a single set of compiler agnostic XML files that can be used to generate vcproj files for all compilers. This will involve mapping and/or removing some compiler options from some compilers that don't support them and should allow for selectively including platforms and or configurations and should also allow for some simple macro token replacement to allow for optional inclusion of things like STLPort include and lib directories and the easy relocation of output directories, etc. Once this is done the final stage is to write some code that will take a VS2008 solution and generate the compiler agnostic files from it so that I can develop in VS2008 and then simply convert from there to all other compilers.

In other news... I've also retooled my automatic CruiseControl.Net project file generator so that it builds project files for the new SVN structure. This has removed several CVS specific work arounds and eased my rules on just how isolated each server example build should be (we now check that the whole pack builds rather than checking that each example in the pack builds in isolation, this means that we only build the shared code once per pack). This has all had the effect of greatly reducing the amount of file copying and building that goes on and has improved the speed of the build considerably; which is nice.

2 Comments

Len, it sounds like you are recreating cmake (www.cmake.org)...

At work we use it to generate VS2008 solutions/projects, and have found it to be a far better approach than the manually maintained solutions/projects we used to have.

Thanks for the reminder. I had looked at cmake last year when I was looking into this problem then; there was a reason that it wasn't suitable, i'll have to take a look at my notes and another look at cmake.

Thanks for the reminder.

Leave a comment