texinfo breakage

Bruce Evans bde at zeta.org.au
Sat Jul 26 03:36:13 PDT 2003


On Thu, 24 Jul 2003, Ruslan Ermilov wrote:

> On Fri, Jul 25, 2003 at 12:20:32AM +1000, Bruce Evans wrote:
> > There is harm for the general case of sys.mk.  Apart from being
> > incompatible with the POSIX rules, it is just wrong to build
> > targets in the same directories as the sources in general.
> > "-o ${.TARGET}" does this (${TARGET} for source .../foo.c is
> > .../foo.o).
> >
> Not quite.  If source is src/foo/bar.c, the object file will be
> put in ${.OBJDIR}/src/foo/bar.c, and such a Makefile should
> then take care of creating ${.OBJDIR}/src/foo, which libgmp/Makefile
> in RELENG_4 does.

This is what happens when the path is relative.  src/foo/bar.c is
relative to ${.CURDIR} (at least if the file is found there), and it
gets transformed to ${.TARGET} = src/foo/bar.o.  It's unclear what
this path is relative to.  I think it is relative to ${.CURDIR} iff
${.OBJDIR}/src/foo/ doesn't exist.

My tests used the relative path ../src/foo.c.

Absolute paths would have no ambiguity and would put the ${.TARGET}
in the same directory as the source.

> > I think sys.mk needs to use "-o ${.PREFIX}" or
> > "-o ${.TARGET:T}" if it uses -o at all, although for .c.o this
> > just gives the same behaviour including exposing bugs as not
> > using -o.  Most or all of the current uses of "-o ${TARGET}"
> > are wrong.
> >
> Hm, that made me think.  ${.TARGET:T} is not the same as ${.TARGET}.
> If source is foo/bar.c, then the .c.o rule should provide a command
> to build its ${.TARGET}, foo/bar.o, not bar.o (${TARGET:T}), like
> it currently does.

But that is incompatible with the POSIX rule and the normal cc rule.
foo/bar.c gives bar.o, not foo/bar.o.  The normal cc rule is part of
the spec of c99 in POSIX (<pathname>.c -> $(basename <pathname>).o).
The POSIX .c.o rule for make just accepts this default.  Any non-null
override of it would be a bug.

> > I think it is mostly
> > accidental that bsd.lib.mk has some support for it.
> >
> Err, HAD some support.

Still has :-).  E.g., it (and other bsd.*.mk) has things like:

	OBJS+=		${SRCS:N*.h:R:S/$/.o/}

Since there is no :T here, all path prefixes in ${SRCS} are preserved,
and when we use ${OBJS} the objects are expected to be outside of
${.OBJDIR} if there are any non-null path prefixes in ${SRCS}.  This
is most evident in the ar command.  If objects are built in ${.OBJDIR}
according to the new rules, then ar can't find them.

Bruce


More information about the freebsd-ports mailing list