Custom Build Really Rules in MS Visual C++ 2005
Recently I was playing around with parser generators and came across a new feature of MS Visual C++ 2005 which is called “Custom Build Rules”. The MSDN article “Understanding Custom Build Rules in Visual C++ 2005: Building Flex and Bison Files from the IDE” describes in details how to use them and gives a link to FlexBison.rules, the file with build rules for Bison and Flex. It’s good news for those who work with parser generators and similar stuff in Visual C++ since it makes working with any input files such like Bison grammars as easy as it is with common C/C++ source files. There is no longer need to specify build commands for each file individually.
Note that there is a bug in the original FlexBison.rules file. To reproduce it first change the output file name for gmath.l. For example lets change it from "lex.$(InputName).c" to "$(InputName).lex.c".
Then make appropriate changes to TinyMath project such as removing lex.gmath.c, building and adding gmath.lex.c. You should also disable usage of precompiled headers for added file.
After this is done you may notice that when you build your project gmath.l is always compiled even if it was not changed since the last build.
It seems that when deciding whether to build file or not modification time of source file and the default output file is compared. Since the latter doesn’t exist if you change the output setting you’ll get your code built every time.
In "Custom Build Rule Properties" you can see that the value of "Outputs" property is defined in terms of "$(InputName)" macro.
I thought that it could be fixed by setting “Outputs” property to "[OutputFile]" which should be expanded to the value of "Output File" property controlled by the user. However, this doesn’t help and thus I decided to get rid of "OutputFile" property at all not to mislead that it works correctly. Here you can get the modified version of FlexBison.rules with "OutputFile" properties removed.
Apart from this issue with outputs, custom build rules functionality turned out to be very useful so I spent some time writing rules for my favourite parser generator Elkhound and AST generator utility that comes with it. Rules for both of them are combined in one file called Elkhound.rules that you can get from here.
That's how it looks like:
