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). 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". >> 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. 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. >> 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.
Attachment:
pgpgC3PQ1JFwI.pgp
Description: PGP signature