Date: Tue, 6 Oct 2015 13:00:45 -0700 From: Bryan Drewery <bdrewery@FreeBSD.org> To: "Simon J. Gerraty" <sjg@juniper.net> Cc: Warner Losh <imp@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r288911 - head/share/mk Message-ID: <5614286D.7020904@FreeBSD.org> In-Reply-To: <15356.1444161040@chaos> References: <201510060418.t964Innu071170@repo.freebsd.org> <56140CAD.8080200@FreeBSD.org> <15356.1444161040@chaos>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OGfbECOx08J1i4lG9e2WJXTm87D7JQfv4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 10/6/2015 12:50 PM, Simon J. Gerraty wrote: > Bryan Drewery <bdrewery@freebsd.org> wrote: >> Why would anyone build ports in a sub-dir of src? It's convenient for = a >> vendor building their own product that needs their own ports tree. So= me >> decisions can't easily be changed; if the root of the source code >> checkout is already src/, there is no simple way to avoid the problem.= >=20 > But wouldn't that imply that /usr/src/share/mk is the right set of > makefiles to use for /usr/src/ports/ >=20 > What would you consider the right sys.mk etc would be in such a case? >=20 For our case we want the checked in src/share/mk to be used rather than the older /usr/share/mk as it is easier to support. If there's a problem we fix in our local.sys.env.mk or bsd.port.mk for instance, it will be used by updating the checkout. This was something we backported, without the src.conf inclusion in sys.mk, and were running with fine. Excluding src.conf is enough to satisfy our needs as it prevents a lot of extra environment, variables, and target overrides we have added into our src.conf to avoid touching FreeBSD files where possible. The biggest problem I hit so far was some LOCAL_LIBRARIES we added in that needed their own __L targets in our src.conf, which bleed into non-src builds now and cause obscure errors. Modifying CFLAGS is another that we have a separate src.conf and ports_make.conf value for, with a shared make.con= f. The changes made by including src.*.mk have not been a problem for us so far. There's really not much hidden from /usr/share/mk except some src-only option handling and library lists. It's possible the inclusion of the meta mode "src".*.mk files could cause problems for us, but I haven't investigated it yet. My biggest problem here is that lack of _WITHOUT_SRCCONF support in bsd.port.mk. The nested build of a non-src build in src/ is easily handled by a -m argument, or using gmake as the upstream was expecting it to be anyhow. In the case we've hit this we have a BSD Makefile that calls the upstream build, so we can control what make arguments and other environment are done from there. However, a user going into src/ports and typing 'make' will get the src.conf pulled in with other surprises. --=20 Regards, Bryan Drewery --OGfbECOx08J1i4lG9e2WJXTm87D7JQfv4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJWFChtAAoJEDXXcbtuRpfPHNQH/0ZI7n7+TsIZ/gsLpRoVwvtd Q9b2eRjyPoe38ZzSKHEzk0EJKPHsfoqY0ilnWn/LPlFMR6ENJ46O5g/uXGR7jnTj llTNk1VyGPpECmgFpk3lhbCB/tvK+JDmGA+/mP9hYmG0yMiTJTZoc8IHeWo2ww9z 7EqEvhAoMlEoHcvA6GbyHP/rD3ebUh6u9IKlAmzzTKHISDulc+f87lJatoTfEUPa fo19QMWsByYEN4rVyk8rtl4q53jJ5RWa2NqP0X1nnk+JdnrYam6cFrjjeZnzdXD4 GSCJGmD1Qwu4NM4I/PexaA92AdJXmlcsf8skKyyhVZnLKN8imbYJHK7JwLoqT6I= =ZmYX -----END PGP SIGNATURE----- --OGfbECOx08J1i4lG9e2WJXTm87D7JQfv4--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5614286D.7020904>