Date: Thu, 24 Jul 2003 17:42:52 +0300 From: Ruslan Ermilov <ru@FreeBSD.org> To: Bruce Evans <bde@zeta.org.au> Cc: Kris Kennaway <kris@obsecurity.org> Subject: Re: texinfo breakage Message-ID: <20030724144252.GA51904@sunbay.com> In-Reply-To: <20030724234927.I4402@gamplex.bde.org> 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> <20030719213127.GB68178@sunbay.com> <Pine.BSF.4.56.0307241017570.86658@acrux.dbai.tuwien.ac.at> <20030724091106.GB15880@sunbay.com> <20030724113914.GA839@rot13.obsecurity.org> <20030724132123.GC37686@sunbay.com> <20030724234927.I4402@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--OXfL5xGRrasGEqWY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Jul 25, 2003 at 12:20:32AM +1000, Bruce Evans wrote:
> On Thu, 24 Jul 2003, Ruslan Ermilov wrote:
>=20
[...]
> I think the full pathnames to sources in the makefiles are just style
> bugs except here.
>=20
Yes.
> > So now we need to decide: do we want to support bogus SRCS with
> > paths in bsd.{prog,lib}.mk or not. Previously, we only supported
> > it in bsd.lib.mk, but not in bsd.prog.mk. Also, POSIX standard
> > suffix transformation rule for .c.o looks like this:
> >
> > .c.o:
> > ${CC} ${CFLAGS} -c ${.IMPSRC}
> >
> > That is, no -o for cc(1). We cannot fix POSIX rules, and if
> > we fix the non-POSIX rules in sys.mk (as shown in another
> > attached patch), the two sets of rules will differ even more.
> > OTOH, there's no harm in having these additional -o's in the
> > normal case of SRCS without path prefixes. So, what do we
> > do with this? Should I commit the attached patch to sys.mk,
> > or should I just fix this makefile to use another .c.o rule?
>=20
> 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).
>=20
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.
> 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.
>=20
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.
> Specialized makefiles can reasonably want to build objects outside
> of the object directory, but this is very un-[Free]BSD-makefile-like
> so I wouldn't want to support it in bsd.*.mk.
>=20
I agree this is unnatural for BSD environment (actually, the objects
are built in a subdirectory of the object directory). But by adding
these additional -o's we can support these cases, and also don't hurt
the normal case of canonical SRCS.
> I think it is mostly
> accidental that bsd.lib.mk has some support for it.
>=20
Err, HAD some support.
Cheers,
--=20
Ruslan Ermilov Sysadmin and DBA,
ru@sunbay.com Sunbay Software Ltd,
ru@FreeBSD.org FreeBSD committer
--OXfL5xGRrasGEqWY
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)
iD8DBQE/H/BsUkv4P6juNwoRAuk7AJ0X+G1lKZPxW6qRCY5Neki/tfVuUACdGSO8
v93BOjQGZnlPjqHF9qdzjlg=
=atCN
-----END PGP SIGNATURE-----
--OXfL5xGRrasGEqWY--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030724144252.GA51904>