[Omake] Implicit rules with path

[Aleksey Nogin]

On 13.11.2006 01:11, Brandt, Oliver - ESD-ES wrote:

> Now my problem: With Dmake we are often using implicit rules like the
> following:
> 
> out/%.obj : %.c
> 	<compile>
> 
[...]
> Question: Is this behaviour (not to match an implicit rule with a path
> in the target) as expected? If so: Is there the chance that OMake could
> behave as every make tool in this case? 

Short answer - the behavior is expected and is not easy to change, but 
can be worked around in several ways.

Longer answer - the reason why this is not easy to change has to do with 
OMake's approach to modularity. A major design goal of OMake is to help 
in "isolating" subprojects within a project from each other, so that by 
changing how a certain subproject is built one would not unintentionally 
break something in another subproject. The way this is implemented is 
through a scoping mechanism, where variable assignments, implicit rules 
definitions, and so on do not apply to the whole project. Instead they 
are scoped so that they would usually apply only to the "current" 
subproject (see the general section on scoping and the section on rule 
scoping in documentation for more detailed explanation -
http://omake.metaprl.org/omake-doc.html#section:section and 
http://omake.metaprl.org/omake-doc.html#htoc85). And it turns out that 
this modular scoped semantics of the OMake language makes it quite hard 
to come up with a consistent way of interpreting implicit rule with a 
path in the target. In other words, it's not only a question of it being 
hard to implement, but even coming up with a consistent description of 
what such rules would mean in different situations is hard.

Fortunately, there are many workarounds.

1) As Dirk have mentioned, one option is to simply use explicit rules. 
For example

foreach(f, $(glob *.c))
    out/$(replacesuffixes .c, $(OBJ), $f): $f
        ...

This is a bit unsatisfying (as you essentially end up manually 
reimplementing something similar to what OMake implicit rules mechanism 
ought to give you).

2) Another option would be to compile the binaries in place and then 
copy (or symlink) them to the out directory.

3) Yet another option would be to use vmount (I am not too familiar with 
it, but other people on the list should be able to help you out if you 
decide to try that option).

4) Another option would be to use active rules:

%.obj:
    section rule
       f = $(file %f)
       src = $(replacesuffixes $(OBJ), .c, src/$(in $(ROOT)/out, 
$(string $f)))
       %$(OBJ): $(src)
          ...

This would still have the disagvantages similar to those of approach (1)

5) An interesting long-term option would be to investigate allowing lazy 
variables on the right-hand-side of the implicit rules. If OMake would 
support it, then we would be able to use something like:

OUT = $(absname out)
SRC = $(absname src)
relocate(f) =
    return $(replaceprefixes $(OUT), $(SRC), $(absname $f))

%$(OBJ): $`(relocate %.c)
    ...

The advantage of this approach over (1) and (4) is that this way OMake 
can still fall back to a different rule for an object file in out if the 
corresponding source file does not exist in src. I just filed this into 
Bugzilla - http://bugzilla.metaprl.org/show_bug.cgi?id=609

Aleksey