Total confusion over toolchain/xdev behavior

[Warner Losh]

On Jul 8, 2014, at 12:56 AM, Dimitry Andric <dim at FreeBSD.org> wrote:

> On 08 Jul 2014, at 03:56, Warner Losh <imp at bsdimp.com> wrote:
> 
>> 
>> On Jul 7, 2014, at 7:29 PM, Warner Losh <imp at bsdimp.com> wrote:
>>> 
>>> About the rest… Yea, you may be right….  MK_GNUCXX is an odd duck, and that’s
>>> likely the problem that should be fixed in a different way. It is really an internal
>>> variable that should be set based on the actual compiler type (possibly with an
>>> override for the odd-duck pair of clang and libstdc++ which may not be worth
>>> supporting). It is telling us we’re doing something horribly wrong and we should listen
>>> to that rather than add another compiler-related kludge to the build system.  I’ll work
>>> on that bit.
>> 
>> Perhaps
>> 	http://people.freesbd.org/~imp/patch-queue/86gnucxx
>> might be the best way to cope…
>> 
>> Comments?
> 
> This would make it impossible to build libstdc++ with clang, and why remove MK_GNUCXX at all[1]?

Because it is a silly option that’s mostly an internal knob? We don’t need to support options that trip us up at every turn, and MK_GNUCXX has been doing that since its introduction.

> Maybe the option should be renamed to MK_LIBSTDCXX or MK_LIBSTDCPLUSPLUS, since that is basically what it does: enable or disable building libstdc++ and its dependent components.

No. Absolutely not. I categorically refuse. This is the *WRONG* way to do this.

If it is to be an option at all, it has to (a) get set correctly when the compiler changes (it doesn’t today), (b) not override the user’s choice (which is impossible today).

> If the compiler is base gcc, you *must* build libstdc++, since it cannot build libc++.  But if you are using e.g. gcc 4.8 as an external toolchain, you could just as easily disable libstdc++, and build libc++ instead.  I think both should be a user-selectable option.

It needs to start working, or it needs to be removed. IT is that simple. I’m tired of mopping up options that only half-assed work to support configurations that aren’t even close to official on the theory that they might be someday used which in turn causes real problems for supported configurations.

So, if we can support it without having the user have to care about it except in the bad-shit-crazy cases, I’m all for that. Otherwise, it has to go. What we have now just isn’t cutting it.

Warner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20140708/9bb53b90/attachment.sig>