Date: Sat, 26 Jul 2003 20:36:03 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Ruslan Ermilov <ru@FreeBSD.org> Cc: Kris Kennaway <kris@obsecurity.org> Subject: Re: texinfo breakage Message-ID: <20030726201459.S5435@gamplex.bde.org> In-Reply-To: <20030724144252.GA51904@sunbay.com> References: <1057992291.42958.21.camel@shumai.marcuscom.com> <Pine.BSF.4.56.0307131243370.945@acrux.dbai.tuwien.ac.at> <20030715034041.GA19804@rot13.obsecurity.org> <Pine.BSF.4.56.0307151336300.26555@naos.dbai.tuwien.ac.at> <Pine.BSF.4.56.0307241017570.86658@acrux.dbai.tuwien.ac.at> <20030724113914.GA839@rot13.obsecurity.org> <20030724234927.I4402@gamplex.bde.org> <20030724144252.GA51904@sunbay.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030726201459.S5435>