[Omake] Re: vmount problems

[David Kågedal]

Aleksey Nogin <nogin at cs.caltech.edu> writes:

> On 08/30/2006 07:24 AM, David Kågedal wrote:
>
>> Is there maybe some discussion of this somewhere that I missed?
>>
>
> I was not following the original discussion, but will the new
> "ocamldep -modules" approach to OCaml dependency scanning (see
> http://caml.inria.fr/mantis/view.php?id=4047 and the OMake list links
> from it) alleviate some of these problems?

I think that I'm trying to ask a different question.  I'm actually not
intersted in building OCaml programs at all.  I have never used
ocamldep, and have no immediate plans to start using it soon.

What I'm trying to assess is if "omake" is possible to use as a
replacement for "make" in a large software system with millions of
lines of code and dozens of more or less independent software modules,
and a complex build system building for several target architectures.
Most of it is based on C, with a few other languages and tools thrown
in the mix.

I created a simple test case to see if vmount did in fact not solve
the problem that vpath solves.

Consider the following directory structure:

top/
    OMakeroot
    OMakefile
    src/
        OMakefile
        foo.c
    build/

and the folloging OMakefiles:

--- top/OMakefile
if true
    .SUBDIRS: src
    .DEFAULT: src/foo
else
    vmount(src, build)
    .SUBDIRS: build
    .DEFAULT: build/foo
-------------------------

--- top/src/OMakefile
CProgram(foo, foo)
-------------------------

If I cd to top/ and type "omake", it will build src/foo without
problems.

But if I change "true" to "false", so it tries to use the vmount, it
will fail with the following message:

   Do not know how to build "src/foo.o" required for "build/foo"

The most important question I'm asking is whether this is a limitation
of the C scanner, the implementation of vmounts, or something more
fundamental?  Or whether there was something I missed?

Adding a -l flag to the vmount call will "solve" the problem, but that
was not the answer I was looking for.

-- 
David Kågedal