svn commit: r288911 - head/share/mk

Bryan Drewery bdrewery at FreeBSD.org
Tue Oct 6 20:00:56 UTC 2015


On 10/6/2015 12:50 PM, Simon J. Gerraty wrote:
> Bryan Drewery <bdrewery at 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.  Some
>> 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.
> 
> But wouldn't that imply that /usr/src/share/mk is the right set of
> makefiles to use for /usr/src/ports/
> 
> What would you consider the right sys.mk etc would be in such a case?
> 

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.conf.

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.

-- 
Regards,
Bryan Drewery

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/svn-src-all/attachments/20151006/b92ae953/attachment.bin>


More information about the svn-src-all mailing list