[kbuild-devel] Re: State of the new config & build system
On Mon, 31 Dec 2001 20:03:59 -0800, Mike Touloumtzis <[EMAIL PROTECTED]> wrote: >On Fri, Dec 28, 2001 at 12:57:58PM +1100, Keith Owens wrote: >> >> Unlike the broken make dep, kbuild 2.5 extracts accurate dependencies >> by using the -MD option of cpp and post processing the cpp list. The >> post processing code is slow because the current design requires every >> compile to read a complete list of all the files, giving O(n^2) >> effects. Mark 2 of the core code will use a shared database with >> concurrent update so post processing is limited to looking up just the >> required files, instead of reading the complete list every time. > >Why not use '$(GCC) -c -Wp,-MD,foo.d foo.c' to generate the dependencies >as a side effect of the regular compile step? This enables you to skip >the initial dependency preprocessing step entirely, and could lead to a >speedup over even the current fastdep system. You still have to massage >the dependencies but you can do it based on the side-effect dependency >output of the _previous_ build, to whatever degree that output exists. That is exactly what kbuild 2.5 does. The slowdown occurs when massaging the -MD dependencies from absolute names to relative path names. To support separate source and object trees, renaming of trees, different names in local and NFS mode etc., the massage code needs a list of where all the files are before it can convert the absolute dependencies produced by gcc. Reading and indexing that file for every compile is _slow_. Larry McVoy has sent me the source code to an mmapped database (from bitkeeper). Using a shared mmapped database should speed the process up considerably. ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: State of the new config & build system
Christoph Hellwig <[EMAIL PROTECTED]> said: > On Fri, Dec 28, 2001 at 03:39:02PM -0500, Eric S. Raymond wrote: > > It may be that the reason our experiences have been different is > > because we focus on different target languages. But I think my > > experience is an existence proof that there *is* demand for > > localization and that meeting it can have useful results. > Is your native language something different thæn english or Al's? > > Localization for technical messages sucks. badly. > Just take a look at a european computer magazine, you will find lots of > english words in the text because there is no german/frensh/whatever > one. Trying to use different grammar doesn't help the understanding. It is even worse when they try to "translate" the terms. In Spanish, the official language calls a computer "ordenador" (sorting device), and a file "fichero" (filing cabinet). It doesn't help in the least at understanding the _English_ documentation/source/... Add to it that here in South America they usually take over the English terms, using "computador" (computing device) and "archivo" (file). So it can even make it hard to understand the technical literature in your own language... My standard advise is to learn English, if nothing else for uniformity's sake. You'll need it anyway before long in anything related to computing. And it is quite useful in other areas... -- Horst von Brand [EMAIL PROTECTED] Casilla 9G, Vin~a del Mar, Chile +56 32 672616 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: State of the new config & build system
[Mike Touloumtzis] > Why not use '$(GCC) -c -Wp,-MD,foo.d foo.c' to generate the > dependencies as a side effect of the regular compile step? As Keith said, kbuild 2.5 *does* use 'gcc -MD' - although the *current* system does not. Linus has said that he doesn't like -MD, and he has a point: it only extracts dependencies for your *current* compile, which means they have to be rebuilt if you change CONFIG options. However, those CONFIG options would cause rebuilding of the file *anyway*, and -MD is almost free since the preprocessor already has to read the files in question, so I'm not convinced that it's a big deal. > The "build whole clean tree" case is a common one even among kernel > developers, e.g. for compile-testing patches before resending them. One of the main points of kbuild 2.5 is that, unlike the current system, it tracks dependencies perfectly. Thus you should almost never have to run 'make clean' before test compiling something - unless you need to see non-fatal compile warnings. It may take some time to get used to the soon-to-be new reality of "ok, so I just applied eight kernel patches from three different places but I know I don't need to bother with 'make clean' because the dependency system is just *that good*." Peter ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: State of the new config & build system
[EMAIL PROTECTED] (Peter Samuelson) wrote on 31.12.01 in
<[EMAIL PROTECTED]>:
> [Alan Cox]
> > > > find $TOPDIR -name "*.cf" -exec cat {} \; > Configure.help
>
> [Horst von Brand]
> > > cat `find $TOPDIR -name "*.cf"` > Configure.help #;-)
>
> [Arnaldo Carvalho de Melo]
> > whatever is faster, do you have trustable benchmark numbers? ;)
>
> Fewer forks vs. increased parallelism ... depends on the nature of your
What parallelism? Neither version seems to have any.
> bottlenecks, I guess, and cold vs. hot cache. Or you could have it
> both ways:
>
> find $TOPDIR -name \*.cf | xargs -n10 cat > Configure.help
>
> ...where 10 is tuned by benchmarking. (:
Not *there* you actually do have parallelism.
> > Yes, its a joke, have a nice 2002 all!
>
> Yeah, same from me..
Yeah, yeah, that stuff ...
MfG Kai
___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
