Date: Fri, 10 Nov 1995 17:24:05 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: rkw@dataplex.net (Richard Wackerbarth) Cc: terry@lambert.org, current@freebsd.org, hackers@freebsd.org Subject: Re: config, other kernel build tools Message-ID: <199511110024.RAA04931@phaeton.artisoft.com> In-Reply-To: <v02130515acc986171d12@[199.183.109.242]> from "Richard Wackerbarth" at Nov 10, 95 04:53:37 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >> I certainly have no problem with that location in src/ > >> Now I'll throw in the "ringer". gcc and make are also "tools". > > > >I think I can safely argue that you're not allowed to include them > >because they aren't allowed to change as frequently as the config > >program. 8-). > > Frequency of change is NOT the criteria. It is the fact that it might need > to change and that it is needed to accomplish a particular compilation of > some version of the tree. > > The generic build files already recognize that you might not want to use > the same c compiler all the time. In the same way, you do not wish to use > the same config. > And in the case of make, Poul is already talking about modifications. There > is nothing wrong with that. But the new version of make should not be > installed into the running system. It may get there eventually, but in the > interim, it belongs in a separate area associated with the build that needs > it. I think that the kernel has to be compilable with any compiler. But not configurable with any config. I think make is close to in the same boat with config, actually, because there are dependencies on features not generic to all make utilities that are used in the tree. On the other hand, config semantics change with kernl architecture changes, and while makefiles do the same, make semantics do not. This is a nearly natural division of the code into three independent categories. It's possible to push this to two if the makefiles can be made to be independent of the BSD make. This is probably a reasonable goal for the kernel itself, but not for the non-kernel portion of the source tree. I should be able to build a kernel on an SCO Xenix box using an SCO Xenix compiler and make utility from SCO, but that doesn't mean I won't need to hack the boot code because the current loader can't understand the image layout, the assembly code because it *is* tool dependent, or that I can use SCO's config tools (which they don't have one of anyway). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511110024.RAA04931>