On some days you just wonder why people create their own build system when they have no experience in doing so at all. Today is such a day. I have seen released source code for a project that is built about the following way:
1. Copy some template config file and manually change settings as you whish. --- Ok, this is not state of the art but acceptable.
2. Fix some Perl script needed in the next step by replacing hard coded paths with the ones appropriate for your system.
3. Use the Perl script to build an executable required for the build system.
4. Fix some other Perl script by again replacing hard coded paths with the ones appropriate for your system.
6. Run this Perl script to build the actual build system.
7. Build the software with the build system built in former steps.
Easy, isn't it?
Some of you might have noticed already that there is step 5 missing. This is intentional because in step 6 you notice that the Perl script does still fail because the executable from step 3 cannot find a specific file. I'm not sure yet who is responsible to provide this file but obviously there must be a magic undocumented step 5 which either provides the missing file or fixes the broken Perl script.
I have seen similar build system adventures at some commercial software vendors but they at least assure that it works if you perform all steps as required, i.e. there typically is no missing step 5. The maximum of build-system-uses-another-build-system-uses-another-build-system recursions I have seen in real world productive development environments for applications written in C so far is 7 recursion steps. Anyone here that has seen more?
How hard must an average developer be penalized by his own build system before he accustoms himself to well established build tools instead of trying to reinvent the wheel?
No comments:
Post a Comment