[Omake] New commercial user of omake

[Aleksey Nogin]

On 28.09.2007 02:07, Alain Frisch wrote:

> - Small suggestion for C.om: make it possible to use different CFLAGS 
> for the actual compilation and the dependency scanning (e.g. you don't 
> want to see warning twice). In addition to CFLAGS, there could be
> CFLAGS_DEPENDS and CFLAGS_COMPILE, or something like that.

Would it be sufficient to have the scanner rules use CFLAGS_DEPENDS in 
place of CFLAGS and have CFLAGS_DEPENDS default to $`(CFLAGS)?

> - Microsoft tools like to pollute their stdout/stderr with useless 
> messages than cannot be disabled (AFAIK). For instance, the C compiler 
> cl will always write the name of the compiled source, and the linker 
> display messages like "Create library ... and object ...". This is 
> annoying because it messes up with the neat OMake progress bar and 
> distract from real warnings. I'm experimenting with an ugly workaround:
> 
> Shell. +=
>   cl(argv) =
>     cl.exe $(argv) |& tail -n +2
> 
Yes, it's really unfortunate that MS there is no good way of disabling 
the junk output. Piping the output through a filter is probably the best 
option - we'll have to add something like that to the default distribution.

> - When I change the OMakefile, move files around or changes the 
> directory structure, I sometimes have to do an "omake -U". Is this 
> supposed to happen, or is this rather an indication that some 
> dependencies are ill-specified? 

This is not supposed to happen and would likely indicate that the 
dependencies are incomplete.

> Btw, it would be great to have some tools to debug dependencies.

If you know what the dependencies are "supposed" to be (or if you have a 
suspicion of what dependencies my be missing), you can run omake with 
various debug flags to see what it's view of dependencies is.

> For instance, omake could be instructed to 
> use a random ordering to build the project (amongst all the orderings 
> compatible with the dependencies). 

That might be a good idea. For now, you could try a parallel build (with 
a large level of parallelism) - this is usually a good test.

Aleksey