Re: Building a source multiple times

[Steven Knight]

David--

> I would like to get your opinion. We have developers who want to compile a 
> source file multiple times using different preprocessor symbols in the 
> same build. The objs are then linked into various executables. It's not 
> what you think of as a variant build really because they might do this for 
> test code or other purpose. Each developer may use a different symbol, 
> since their code is not coupled with the other developers code. What I am 
> trying to say is that you couldn't do a "test" variant, or some other 
> thing. If we use variant builds we would have 20 different variant builds, 
> and they are all used for the same product on the same platform. You can't 
> organize it like debug and release, or windows and unix.
> 
> So the question is what do you think is the best way to solve this 
> problem?
> 
> We are using Cons::Plus as well as some of our own code. The current plan 
> is to use install to temporarily copy the file to a new place to trick 
> Cons into not knowing it is the same file. My worry is that we confuse 
> Cons so much with this stuff, that it becomes just as unreliable as what 
> we are doing now (Dev Studio).
> 
> Finally, I am wondering why the need to compile a file more than once in 
> the same variant build is not supported. My guess is that the original 
> designers didn't consider this practice. By the way, I have argued 
> extensively against this practice here, but to no avail.

It basically sounds like you want to give developers the chance to set
their own flags on their build(s), right?  You may want to consider
using the -o (override) option and the Override function for this.

The -o lets you specify a file that is read specific to that build.
This file could contains special target(s) that are defined only for
that build, but the real power is if the file contains the Override
function.  You use this to specify a pattern to be matched, and a hash
of construction variables whose values will be set/overridden for
the build.

Since the override files can be checked in, you can use this to create a
stock set of override "flavors" that can be used for builds.  Here's an
example (typed off the top of my head, so beware of typos):

        $ cons .
        cc -o
        cc -c main.c -o main.o
        cc -o main main.o
        $ cat my_build
        Override '.o$', COPT => qq(-DMY_BUILD);
        $ cons -o my_build .
        cc -DMY_BUILD -c main.c -o main.o
        cc -o main main.o
        $

I've only had occasion to use -o once or twice myself, but off the top
of my head, I think it's the right solution for your situation.

        --SK