Re: defaulting to clang on FreeBSD 10.x

[rodent%NetBSD.org@localhost]

On Sun, Mar 22, 2015 at 01:39:50PM -0400, Greg Troxel wrote:
> 
> rodent%NetBSD.org@localhost writes:
> 
> > On Sun, Mar 22, 2015 at 01:07:51PM -0400, Greg Troxel wrote:
> >> 
> >> Perhaps it would be better to have an error if the compiler pointed to
> >> by PKGSRC_COMPILER is not found.  I'm generally not a fan of trying to
> >> patch around misconfiguration, as it often seems to lead to more and
> >> more complexity.
> >
> > I think the way it works now is correct. "Oh, you want that compiler? Don't
> > have it? Let me build it for you." What you're proposing involves more work
> > for the user and seems to be more complex.
> 
> Before we change anything to support this case, I'd like to understand
> how we're going to build a compiler when we don't have a compiler to use
> with it (the case of PKGSRC_COMPILER=gcc when gcc is not found).

Oh, sorry. I see what you're saying now. 1) User has foo-c; 2) User wants
bar-c; 3) User sets PKGSRC_COMPILER=bar-c in mk.conf; 4) pkgsrc framework
fetches bar-c package, but then how to compile it? Yes, that would be a
problem for which i don't have a quick solution and wasn't proposing to solve
at the start of this thread. ;)
 
> There's also the issue of PKGSRC_COMPILER=gcc when there is a 'gcc' but
> it's really clang (e.g., on OS X 10.9).  Probably that doesn't work so
> well, but that's in the category of "bootstrap doesn't set that up" and
> "well don't do that then".

The get_compiler function of bootstrap which asau@ pointed me to earlier
_does_ seem to handle that case. Though, what i'm saying is if we know
that behaviour exists on such a version of Darwin, we can code that into the
framework in a similar way my patch does, not make bootstrap do all those
checks, and that makes for less code for bootstrap and a smaller resulting
mk.conf file.

> >> Or perhaps on other than NetBSD (where we don't bootstrap and hence an
> >> empty mk.conf is ok), failure to set PKGSRC_COMPILER in mk.conf should
> >> error out immediately with a helpful message.  The bug may be that it's
> >> ?= to gcc in the first place.  I can't find that on a quick skim of the
> >> code.
> >
> > That's more work for the user still. The framework can be smart to know that
> > gcc is part of NetBSD already, so why not default to if it not set elsewhere?
> > Ideally, there would be as few options as possible that the user would need to
> > set and maintain in mk.conf
> 
> Right now bootstrapping creates a mk.conf, and one can't arbitrarily
> munge it without understanding.  That's more or less part of our design
> and/or interface spec, and generally it has not been an issue.

In an ideal world, yes: Users would know what they're doing before changing
config files and we can count on them to be informed and make the correct
decisions all the time. However, isn't a valid user question - let's say a user
coming from NetBSD where all those variables aren't set and the framework
DTRT - If I unset these variables and have just one compiler on my system,
will the framework DTRT here too?  In this case, the framework can be smart
and provide the system defaults in the absence (for whatever reason) of those
variables.

> pkgsrc on NetBSD itself has long been a special case, where we don't
> bootstrap, and thus have an accomodation for not using the standard
> approach.
> 
> > (note i'm considering bootstrap as a user, too).
> 
> I'm not really sure what that means or if it is a good goal;
> bootstrapping is part of the same codebase and therefore can be expected
> to be consistent and correct.

Yes, and bootstrap's codebase can be smaller and generate smaller
configuration files, because the framework would do as much work as possible.

> >> There are also deeper issues in the compiler selection code.   It seems
> >> we can't flip back and forth between clang on gcc (on systems that have
> >> both) because of at least C++ library differences.  But there's code to
> >> force gcc for ada (vs failing).
> >
> > It's sort of outside the scope of this discussion, because i want to address
> > this on systems which don't have gcc by default. That point is interesting and
> > valid though and we'd need to solve it at some point.
> 
> True, it's orthogonal now.  But once we start to talk about how to find
> a compiler to compile gcc when we want to use it and it's not present, I
> suspect it will become non-orthogonal.

Different thread, perhaps? :)