Summarizing a little our conversation from IRC:

* To produce relocatable filenames it makes sense to normalize foo to ./foo and
  not the other way round. (This is actually easily doable if we want to do
  that.)

* We could introduce a new macro that holds the target name that was actually
  used in the target definition and not the normalized version. This would add
  some extra memory and would be moderately invasive.

* The previous solution could be applied to $@, but that would make .WINPATH
  (issue 73499) more or less unusable whenever it is most useful, i.e. for
  absolute paths.

Currently I would tend to only the first bullet if that is good enough, the
problem with it is that errors in string operations are hard to spot, for
example

--------------
mytarget=.//something

$(mytarget):
    echo $(eq,$(mytarget),$@ equal different)
--------------

would still not be equal because the legal, but unneeded second slash in
mytarget would normalized away. Or for
 mytarget=./bla/../something
the bla/.. would be normalized away.

Hmmm, I was just looking into issue 77202 to add a general mechanism foo => ./foo
but now I fail to see why ./foo is more relocatable than foo. I remember there
was an example but I forgot what it was.


For the example in this issue, wouldn't a function macro $(normalize ...) (it
normalizes a given macro as if it would be a target) solve most of our
problems?

Something like this would work:
--------------
mytarget=./something

$(mytarget):
    echo $(eq,$(normalize mytarget),$@ equal different)
--------------

Created attachment 45324 [details]
New normpath function macro

The previous patch implements a $(normpath ..) function macro that implements
a normalization of the given macro. It honors .WINPATH.

Maybe we should have two function macros, one that only normalizes to the internal
representation (not following .WINPATH) ( that should be $(normpath ..) ) and
another called one that follows .WINPATH ( should be called $(winpath ..) ).

Opinions?

I just briefly looked at the ZIPnTARGET problem, and I think the biggest problem
is this

"{$(subst,LANGDIR,{$(subst,$(ZIP$(TNR)TARGET)_, $(@:f:b))} $j )}"

part. So instead of using the foo => ./foo translation (for which I will prepare
a patch anyway) this could also be fixed by using normpath, i.e.:

"{$(subst,LANGDIR,{$(subst,$(normpath ZIP$(TNR)TARGET)_, $(@:f:b))} $j )}"

(Yes, I know, if we go down this road we will have patches all over solenv/inc )

Created attachment 45474 [details]
Add foo/bar => ./foo/bar transformation

The previous patch adds a general foo/bar => ./foo/bar transformation to work
around mentioned in this and issue 77202. I had to add the additional requirement
that at least one directory separator is present because otherwise some internal
targets and more importantly imported environment variables would also get ./
prepended. (A can of worms ...)

Contrary to what I said on IRC, I don't like this anymore, and the simple patch
from issue 77202 that only disables the stripping of leading ./ sounds like
the best way around this problem. (Maybe enabled by an command line switch for
an OOo special mode)

The correct version would still be the use of normpath before comparing and
substituting but that's a lot of work ...

Created attachment 45622 [details]
Add special OOo build mode to control the ./foo => foo  normalization

The previous patch introduces a new special macro that can be used to toggle
OOo build specific behavior. If OOOSPECIAL is set (means it begins with y)
the leading ./ of a path will no longer be removed.

The OOOSPECIAL value can be imported with .IMPORT

Example:
- - makefile.mk - -
SHELL*:=/bin/sh
SHELLFLAGS*:=-ce

.IMPORT : OOOSPECIAL

./all :
	@echo $@
- - - -

This will either echo ./all with OOOSPECIAL=yes or just all if OOOSPECIAL is not
set.

Is OOOSPECIAL a good macro name? Maybe we should call it OOODMAKEMODE?

(The patch also contains some extra clean-up and the normalization of leading
slashes, see issue 78061.)

Created attachment 46123 [details]
New patch using OOODMAKEMODE

I committed the previous patch, docu and testcase are still pending.

Testcase committed.

Created attachment 46190 [details]
Man page patch

Documantation change committed.

The $(normpath ..) function macro will be handled by issue 78776. Using the
OOODMAKEMODE macro should be sufficient to emulate the old dmake bahavior.

@ause: Please verify.

.

dmake 4.9 active in MWS

OOODMAKEMODE gets evaluated too late when dealing with explicit targets from the
commandline.

dmake ./ttt

cuts "./" no matter if OOODMAKEMODE is set in environment or startup.mk. even

dmake ./ttt OOODMAKEMODE=YES

doesn't work while 

dmake OOODMAKEMODE=YES ./ttt

does...

no real surprise but quite annoing. any chance to get "./" cut off later (when
startup.mk is evaluated or so...)?

I admit OOODMAKEMODE is a cludge, it's just to work around a problem in the
makefiles that need the leading ./ . It "breaks" the normalizing of the internal
representation of targets. Unfortunately dmake just processes the commandline
arguments in the order of appearance, so that the macro definition of OOODMAKEMODE
has to happen before the target is created, and the target is created once it
appears on the commandline. It might be possible to save the list of targets
mentioned on the commandline and process them after startup.mk is read.

Is it worth the effort? I would vote for putting in the environment, that is
a one line patch for config_office and probably equally easy for the Hamburg
environment.
This would remind us of this problem, and maybe we can get of it at one point by
using $(SOMEVAR:n) or $(normpath ..).

the problem is that even the environment settings (.IMPORT in startup.mk) are
evaluated too late. maybe makeing OOODMAKEMODE a special variable, like
DMAKEROOT(?) could help.

the actual problem i stumbled uppon (rules.mk) can be workarounded by inserting
OOODMAKEMODE=TRUE into each and every recursive call of dmake. but that wouldn't
help when using "./" targets on the commandline (beside being not very intuitive ;))

Ah, I didn't realize that setting the environment variable doesn't help
because the .IMPORT : .EVERYTHING does happen in startup.mk, or never if
it is not set.

Yes, I can treat OOODMAKEMODE like DMAKEROOT. Would this solution be acceptable
if it works? (I'll test later)

If that fails I will try to move the "definition" of the command line targets
behind the evaluation of startup.

Created attachment 48252 [details]
Patch for dmake / OOODMAKEMODE

Patch and testcase committed.

Now OOODMAKEMODE is *always* imported from the environment and the targets from
the command line are defined after OOODMAKEMODE is read from the environment and
after the macros from the command line are set.

Created attachment 48253 [details]
Patch for dmake / OOODMAKEMODE

The previous patch reverts the part of the previous patch that lets OOODMAKEMODE
always be imported from the environment. Instead move the definition of targets
from the command line after the evaluation of the startup makefile.

Committed and testcase changed.

Please verify

works as described

.