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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message