[kbuild-devel] Re: State of the new config build system
On Fri, Dec 28, 2001 at 01:54:42AM +0100, Dave Jones wrote: How far down the list was make it not take twice as long to build the kernel as kbuild 2.4 ? Keith mentioned O(n^2) effects due to each compile operation needing to reload the dependancies etc. Each compile needs to reload deps??? Ug. IMHO if you are doing to shake up the entire build system, you should Do It Right(tm) and build a -complete- dependency graph -once-. Jeff ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: State of the new config build system
On Fri, Dec 28, 2001 at 10:02:01AM -0800, Linus Torvalds wrote: [ Btw, Jeff, any reason why you changed your name to Legacy Fishtank? It took a few mails before I noticed that it also said garzik in the fine print;] Away-from-home account and a long story :) Jeff ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: State of the new config build system
I think one thing to note is that dependencies is that if you are smart about it, dependencies -really- do not even change when your .config changes. What about a system where Linus runs make deps -once- before he releases a tarball. This in turn generates dependency information (perhaps not in purely make format) which includes 'ifdef CONFIG_xxx' information embedded within. We know that make can support ifeq CONFIG_xxx for example... Jeff ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: State of the new config build system
On Fri, Dec 28, 2001 at 03:45:37PM -0500, Eric S. Raymond wrote: Legacy Fishtank [EMAIL PROTECTED]: For single-file drivers, I like Becker's (correct credit?) system... about 10 lines of metadata is embedded in a C comment, and it includes the Config.in and Configure.help info. I proposed implementing something like this about a year ago (to replace the nasty centralized knowledge in the MAINTAINERS and CREDITS files) and was shot down. Note I am specifically NOT talking about MAINTAINERS and CREDITS. -PLEASE- don't obscure my point by mentioning them. Dealing with MAINTAINERS and CREDITS in an automated fashion seems more like pointless masturbation to me. If you want to find out who needs to be CC'd on patches, use your brain like I do. Jeff ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: State of the new config build system
On Fri, Dec 28, 2001 at 10:02:01AM -0800, Linus Torvalds wrote: Something I also asked for the config system at least a year ago was to have Configure.help split up. Never happened. It's still one large ugly file. Driver or architecture maintainers still can't just change _their_ small fragment, they have to touch a global file that they don't own. So if somebody really wants to help this, make scripts that generate config files AND Configure.help files from a distributed set. And once you do that, you could even imagine creating the old-style config files (without the automatic checking and losing some information) from the information. For single-file drivers, I like Becker's (correct credit?) system... about 10 lines of metadata is embedded in a C comment, and it includes the Config.in and Configure.help info. Jeff ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: State of the new config build system
On Sat, Dec 29, 2001 at 12:26:49PM +1100, Keith Owens wrote: On Fri, 28 Dec 2001 16:16:03 -0500, Legacy Fishtank [EMAIL PROTECTED] wrote: I think one thing to note is that dependencies is that if you are smart about it, dependencies -really- do not even change when your .config changes. What about a system where Linus runs make deps -once- before he releases a tarball. This in turn generates dependency information (perhaps not in purely make format) which includes 'ifdef CONFIG_xxx' information embedded within. We know that make can support ifeq CONFIG_xxx for example... Then people apply patches and break. s/break/update dependencies/ I assumed this was blindingly obvious, but I guess not. Jeff ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: State of the new config build system
On Sat, Dec 29, 2001 at 12:27:24PM +1100, Keith Owens wrote: Dependencies _do_ change when your .config changes, the list of files that are included varies. 1) #ifdef CONFIG_FOO #include ... is usually wrong and a bug. But that is a tangent and I digress. 2) Such changes can be expressed without regenerating all dependencies. Linus, you have a choice between a known broken build system and a clean and reliable system, which is slightly slower in mark 1. Please add kbuild 2.5 to the kernel, Your system is known broken because it is 100% slower. My kernel builds work just fine now, your changes gain me nothing, while COSTING me productivity. I see no gains, only costs, with your kbuild-2.5 system as it exists. Keith the target audience is Linus and Alan and ME etc. We are the kernel hackers that perform kernel -development-. Making end-user builds easier is NOT a primary nor secondary nor tertiary goal here. Make my life easier first. Fuck Aunt Tillie. Aunt Tillie can get her kernels from a vendor. Jeff ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
