Section 5.7. Changing Your Build Tool


5.7. Changing Your Build Tool

If you do decide to change your build tool, here are some tips for making the transition a little easier. Section 3.7.1 also has some more general advice on choosing new tools.


Search for advice

Search carefully for examples of how other people have used the new build tool. Create a few local prototypes before going to the effort of creating all of the new build files. Subscribe to the appropriate mailing lists and browse the documentation and any books about the tool.


Start with a working build

Make sure that the existing build is working, at least for the major targets that are used by the project. This will remove a whole range of uncertainties from the conversion process.


Capture all the output from a working build

Generate a text logfile that shows the complete details of every command that the build currently executes, including any warnings from compilers and other tools. Now make your new build tool do what the old one did, as closely as possible. Then when your new build fails in some mysterious way, you will have a working example to compare against the output from the new build. Your existing build tool may well have an argument to increase verbosity and to show the actual command lines that were run.


Use the existing directories

If at all possible, create the new build files for the new build tool using the existing directory structure. This is one less variable changing at the same time. Later, after the build is working, you can start to rearrange directories and rename or split up the source code files.


Use temporary scripts

If there are parts of the original build files that the new build tool doesn't support until you customize it in some way, you can still make progress by hardcoding the old build commands into a script file and calling that with your new build tool.


Compare the results

If you run both the old and new build tool in parallel for a few days or weeks, then you can compare every generated file. It's also reassuring to see how many generated files are identical at a binary level and to understand the differences when they aren'toften this is due to timestamps. Ideally, when you do change over to using the new build tool, no one should see any difference in the files that are generated. You can also run tests to compare the performance of the old and new build tools, which helps encourage other people to use the new build tool.



Practical Development Environments
Practical Development Environments
ISBN: 0596007965
EAN: 2147483647
Year: 2004
Pages: 150

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net