Date: Thu, 07 Feb 2002 14:55:26 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: obrien@freebsd.org Cc: Max Khon <fjoe@iclub.nsu.ru>, Joe Kelsey <joe@zircon.seattle.wa.us>, current@freebsd.org Subject: Re: gcc3.x issues Message-ID: <3C6305DE.190E67D9@mindspring.com> References: <20020206160611.B181@dragon.nuxi.com> <200202070053.g170rjQ19592@aldan.algebra.com> <20020206170904.C181@dragon.nuxi.com> <15457.55061.55399.596297@zircon.zircon.seattle.wa.us> <20020206172554.A1999@dragon.nuxi.com> <15457.56475.172650.789685@zircon.zircon.seattle.wa.us> <20020207131144.A87654@iclub.nsu.ru> <3C624223.4AE24952@mindspring.com> <20020207100125.A53237@dragon.nuxi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
David O'Brien wrote:
> > And hacking the Makefile a lot to specify command line
> > arguments in the compiler program definition itself, so
> > that the /usr/include/g++ files that came with the old
> > compiler are not used for "make release" and other types
> > of make targets where DESTDIR is fairly mandatory.
>
> Terry, we only support building the world (ie, anything in /usr/src) with
> the *SYSTEM* compiler. If you are wanting to do:
>
> cd /usr/src
> make CC=FOOcc CXX=FOO++ buildworld
>
> Then you are going off into the "not-supported woods" and you should
> expect to have to do some hacking.
The problem I noted is C++ only. I'm sure that there are
other cases where it's not, but they're really fuzzy, since
I don't have a comprehensive tool chain listing that can
get me an explosion if anything from the default chain gets
used accidently.
Wasn't Eric Melville going to fix this by turning the normal
system components into packages? 8-) 8-).
For the "buildworld" case, and the "release" case, the
problem is incredibly deeper than just replacing the day
to day use tools, since if you build the compiler as
part of the build, you're screwed already.
You can make an argument for the "release" case using a
different set of tools, since it can install patches and
packages prior to the build process, but the compiler you
end up with will be the "release" compiler, not the
package compiler, even though pretty much everything will
have been compiled with the package compiler (or cross
builds would not work at all). Even so, the interaction
is ugly.
I think Joe's main problem is that it's not documented,
except in the heads of the people who've tried it, or the
people who maintain it.
Yeah, that's a problem, but the only thing we can really
do about it is offer to answer questions, or tell them (or
imply with a "where's the patches?" response) that they
are on their own. Documentation won't magically appear
(e.g.: "where's the patches?" 8-)).
> If you are wanting to use /usr/share/mk for your own projects, then that
> is also a debatable issue. Some claim /usr/share/mk is only for use of
> /usr/src; others feel it should be generic and truely usable for other
> code. If you have some well tested patches to fix the assumptions in
> /usr/share/mk, we might can change things.
Seperate problem. Though if it *were* generic... we might
see the BSD make being more widely adopted. I think this
is one of the tenets of the "Open Ports" project, FWIW. If
nothing else, FreeBSD ought to be pulling back in their
tools changes that they've found to be necessary, so long as
they don't hurt too much ("a little pain is good for you",
according to the penguins...).
Personally, if my projects are limited to FreeBSD, I use the
.mk system, and if they aren't, then I avoid it like the
plague.
Building a project based partly on Open Source is really an
art, more than it is an easy thing to do, though it's often
worth the pain to get the benefits (per my Daemon News article
-- shameless plug).
I think the biggest barrier these days is that there is so
much that is assumed to be "part of the base system" that
is not really generic UNIX, and avoiding contamination from
use of, for example, the FreeBSD version of OpenSSL, rather
than the version in your source tree, requires that the
engineer doing the work cross their T's and dot their I's
correctly, or they will find that their code works on their
developement machine, but not their target machine.
Fixing *that* problem is a lot more than just waving your
hands: it requires duct tape and prayers, since you will
find yourself fixing the software packages you depend upon,
too (this is the major drawback of autconf/automake: unlike
imake and xmkmf, they really aren't portability tools, and
can't make a program run on a new target through a correct
description of the target, like imake can -- e.g. MySQL now
runs on AIX again because I hit my head on it, and there
are 5 or 6 other Open Source projects that got patches out
of my last round of head hitting).
In any case, it's often hard to discuss Hoover Dam when you
are running low on fingers plugging holes in the local levy;
know that your work on the levy *is* appreciated, since we
would all be under water otherwise.
I'll look at what it will take to fix the DESTDIR stuff
without breaking things. That's a far cry from what Joe
wanted, but it's a step in that direction, anyway. It's
going to boil down to tracking down everywhere it's used
in the source tree as is, particularly with regards to
the "make release" case, where the headers have to come
in from the target environment, but also in ports. 8-(.
Fortunately, there is not a lot of C++ code in the release
stuff; the ports stuff will be more problematic, of course,
but much of that is already broken, in that the system
compiler is passed, but the g++ compiler is searched out
and preferred (!@#!$!@ autoconf/automake).
...Uh, don't let me looking at this stop anyone else from
looking at it too... I won't feel offended if someone else
fixes it before I get around to it. 8-).
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C6305DE.190E67D9>