walt wa1ter at myrealbox.com
Sun Apr 10 12:48:19 PDT 2005

On Sun, 10 Apr 2005, Matthew Dillon wrote:

> :>    I don't think we want to rip up our dfports stuff until we actually
> :>    have something to replace it with.
> :
> :That wasn't what I suggested.

My apologies for jumping to conclusions.  I mistook your meaning.

> :Current dfports compiles as freebsd-4.8, GCC 2.95.x is configured for the
> :FreeBSD fall back.  GCC 3.x is not, we need to move forward into using our
> :own uname for compiling ports if you want to rip out gcc 2.95.x like you
> :said in your plans on the 1.2 release page.

I've always wondered why the same configuration could not (or should not) be
applied to gcc34 temporarily so as to avoid the ports crisis while allowing
DF to default to gcc34.

>     Ach, right.  You know I totally forgot we had those uname hacks in
>     there.
>     We still don't want to rip it out quite yet.  The GCC-3-as-default is
>     not something we can do in a week, there's a lot of stuff that is going
>     to go into the HEAD branch all at once and it will probably be at least
>     two months before we slip the PREVIEW tag again.  So we have time to
>     think about how to deal with the ports issue.

Just speculating idly:  if there *is* some reason to avoid configuring the
system gcc34 as __FreeBSD__ then one alternative would be to make a dfport
override for the lang/gcc34 port and configure *that* one as __FreeBSD__
and use it as the 'portbuilding compiler'.  Yes, just a temporary hack, of
course, like filing for an extension on your tax return -- but I do that
every year ;o)

More information about the Kernel mailing list