Ports conflicts: `lib/libiberty.a'

Sergei Kolobov sergei at kolobov.com
Sun Oct 12 02:19:59 PDT 2003

On 2003-10-11 at 15:53 -0700, Ade Lovett wrote:
> No.  Please no.  Oh lordy, no.  The maze of options, variables, hacks, 
> and other bits and pieces needs to be reduced, not increased.  It's a 
> staggeringly complex ball of wax already.

Agreed. Wasn't it you, Ade, who suggested going to something like:

USE_FEATURES=	autoconf automake openldap

etc. Or at least this is what I remembered. ;)
I think this is the approach we should take and I am willing to help
with that unless you have the patches ready. ;)

> A centralized place to refer to these knobs (a purely documentatary 
> bsd.knobs.mk, perhaps) detailing what they are, who uses them, and what 
> they do would go a long way to help, but some of the process would have 
> to be (non-trivially) automated in order to keep it up to date (no 
> small task in of itself).

I think this is overly complex solution for a not-very-complex problem.
There were several alternative solutions proposed on this very list -
somthing like a pkg-options file which list all options local to the
port, together with corresponding bsd.port.mk magic to present a user
with a list of options to choose from, while still allowing to
pre-define them via /etc/make.conf (or some other mechanism) and
providing defaults for BATCH=yes builds.

> I'm really starting to wonder whether we've reached the limits of what 
> can reasonably be accomplished with make(1) as we approach ports10k...

Good question. Do you have any alternatives in mind? I understand that
Darwin was (or is) going to use TCL. At least, I got that impression
from few last commits to now-dead OpenPackages CVS.


More information about the freebsd-ports mailing list