svn commit: r200797 - head/lib/libc/stdtime

[Doug Barton]

M. Warner Losh wrote:
> In message: <4B3129CD.20908 at FreeBSD.org>
>             Doug Barton <dougb at FreeBSD.org> writes:
> : M. Warner Losh wrote:
> : > We really need newer binutils in the tree.
> : > 
> : > And we need a way to compiler gplv3 binutils into the system for folks
> : > that can do that without consequences...  But many modern processors
> : > need to have the gplv3 version of binutils and that will be a
> : > continuing problem.  One advantage of FreeBSD is its integration,
> : > rather than having to play version whack-a-mole like you do with
> : > embedded Linux.
> : 
> : When "we" last had the gplv3 discussion there were two lines of
> : thought that were proposed. One is "import llvm/clang" and the other
> : was "improve the infrastructure to support toolchains from ports." I
> : know that the llvm/clang project is moving forward, and I think that's
> : a great long-term direction.
> 
> Assuming that it supports the architectures we need well, which at the
> present time it isn't clear that it will...

The details of what compiler we use in the base aren't really
interesting to me for the purpose of this discussion. I hope that we
can find a BSD licensed alternative that's suitable for the base, but
I think we are already getting left behind in terms of "things that
require more recent compilers" and it's only going to get worse.

> : In the short term I think we are well served on all fronts to modify
> : the build architecture to better support compilers from ports. This
> : would actually help with the llvm/clang testing too, and sidestep the
> : problems of gplv3 stuff being in the base. TMK there has been no work
> : on this direction at all, which is disappointing.
> 
> The problem is that it really isn't a terribly viable solution, so why
> waste a bunch of time on it? 

You're disregarding this as a possible solution because the concept
doesn't fit your idea of what's possible or desirable. With all due
respect I think closing your mind to the possibility is premature.

> Does the build-world stop in the middle  and rebuild stuff? 

Huh? Are you asking whether a world build with a compiler from ports
should rebuild the port(s)? If so, I think the answer is pretty
obviously no.

> Right now we have finely matched libraries and
> compilers, how does one address that problem with the compiler out in
> the ports? 

One could argue that the current situation is actually not desirable,
and making it more "plug and play" is a good goal regardless of what
compiler we use.

> You'll need a matched set of binutils as well (well,
> matched meaning known compatible here), and the build system has a
> strong bias towards the compiler knowing which ones to use..  These
> problems can all be surmounted, but it just feels like a big kludge.

Funny, I feel the same way about the current system. :)


Doug

-- 

	Improve the effectiveness of your Internet presence with
	a domain name makeover!    http://SupersetSolutions.com/