From owner-freebsd-ports@FreeBSD.ORG Thu Jul 24 07:43:08 2003 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AF07F37B404; Thu, 24 Jul 2003 07:43:08 -0700 (PDT) Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id A99C343FA3; Thu, 24 Jul 2003 07:42:59 -0700 (PDT) (envelope-from ru@sunbay.com) Received: from whale.sunbay.crimea.ua (ru@localhost [127.0.0.1]) h6OEgs0U054046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Jul 2003 17:42:54 +0300 (EEST) (envelope-from ru@sunbay.com) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.12.9/8.12.8/Submit) id h6OEgqWu054037; Thu, 24 Jul 2003 17:42:52 +0300 (EEST) (envelope-from ru) Date: Thu, 24 Jul 2003 17:42:52 +0300 From: Ruslan Ermilov To: Bruce Evans Message-ID: <20030724144252.GA51904@sunbay.com> References: <1057992291.42958.21.camel@shumai.marcuscom.com> <20030715034041.GA19804@rot13.obsecurity.org> <20030719213127.GB68178@sunbay.com> <20030724091106.GB15880@sunbay.com> <20030724113914.GA839@rot13.obsecurity.org> <20030724132123.GC37686@sunbay.com> <20030724234927.I4402@gamplex.bde.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OXfL5xGRrasGEqWY" Content-Disposition: inline In-Reply-To: <20030724234927.I4402@gamplex.bde.org> User-Agent: Mutt/1.5.4i cc: ports@FreeBSD.org cc: ports-committers@FreeBSD.org cc: Bruce Evans cc: Kris Kennaway Subject: Re: texinfo breakage X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2003 14:43:09 -0000 --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--