[Omake] Re: Building in subdirectories and variant builds revisited

[Jesper Eskilson]

2007/6/18, Jason Hickey <jyh at cs.caltech.edu>:
>
> On Jun 18, 2007, at 11:54 AM, Aleksey Nogin wrote:
>
> > On 08.06.2007 05:55, David Kågedal wrote:
> >> I'll go one step further and say that even separate source and build
> >> directories wasn't part of the original design spec.
>
> In defense, the problem is that variant builds are hard in general.
>
> The problem is to come up with a *general* method for variant
> builds.  Not one that works just for gcc, or cl, or OCaml, or any
> specific thing.  It needs to work in general, and on all platforms.
>
> The problem is that some ill-behaved programs are hard to specify.
> Here are some example behaviors of ill-behaved programs.
>
>     - The target and source file must be in the same directory (like
> "cc -c" without a -o option),
>
>     - Programs where the sources can't be specified in the rule.
> ocamldep is an example.
>
>     - Programs where the set of targets is not known ahead of time.
> For example, texinfo generates a bunch of files xxx-1.info,
> xxx-2.info, ... but you can't predict how many files it will generate.
>
> In all these cases, the build rules are necessarily imprecise; they
> miss some dependencies, or some targets, or they might have
> unintended side-effects.

The simplest way to solve this in terms of variant builds is simply to
always run the build command in the build directory; that way all the
outpus (including the "unknown" ones) are placed in the build
directory (where it rightly belongs), and not in the source directory
(where it would "contaminate" other variant builds). This is how
variant builds are implemented in the autotools world.

IMO, the impreciseness of the build rules are really orthogonal to the
issue of variant builds.

> IMO, the real solution is to use a virtual filesystem that provides
> the illusion that the variant build is a real one.

-- 
/Jesper