On Mon, 9 Jun 2003, Christoph Hellwig wrote:
> On Mon, Jun 09, 2003 at 01:56:59PM +0200, Jaroslav Kysela wrote:
> > one object file for more targets. Example:
> >
> > --
> > snd-ice1712-objs := ice1712.o delta.o hoontech.o ews.o ak4xxx.o
> > snd-ice1724-objs := ice1724.o amp.o revo.o aureon.o
On Tue, 19 Nov 2002, Richard B. Johnson wrote:
> I think all you did was increase the compile time by writing
> output files to different directories than the ones currently
> in cache. There are a lot of negatives. It would be a shame for
> you to waste a great deal of time on something that woul
On Tue, 19 Nov 2002, Larry McVoy wrote:
> On Tue, Nov 19, 2002 at 03:22:45PM -0500, Richard B. Johnson wrote:
> > On Tue, 19 Nov 2002, Sam Ravnborg wrote:
> >
> > > Based on some initial work by Kai Germaschewski I have made a
> > > working prototype of separate
On Mon, 11 Nov 2002, Tom Rini wrote:
> Hello. The following patch makes split-include take another argument,
> which is the prefix of what is being split up. This is needed since I'm
> working on a system which will allow for various params in the kernel to
> be tweaked at compile-time, without
On Mon, 4 Nov 2002, Peter Samuelson wrote:
> > Now we only need to convince Peter.
>
> I just sent you a patch with all [M], so I guess you can consider me
> sufficiently convinced. I'm not, really, but it's hardly an important
> issue, so I figured I'd stop wasting all of our time. Besides, I
On Mon, 4 Nov 2002, Sam Ravnborg wrote:
> On Mon, Nov 04, 2002 at 02:21:11PM -0600, Kai Germaschewski wrote:
> > On Mon, 4 Nov 2002, Peter Samuelson wrote:
> >
> > > The idea was that [M] is printed whenever a new module is born.
> > > (M) means a module is in pr
On Sun, 3 Nov 2002, Peter Samuelson wrote:
> With !KBUILD_VERBOSE output, you can't tell whether a CC or LD line is
> for a module or for the kernel proper. Sure, most people probably
> don't care, but *I* do. Hence this patch. Output:
>
> CC vmlinux-object.o
> CC [M] standalone-modu
On Thu, 3 Oct 2002, Sam Ravnborg wrote:
> On Thu, Oct 03, 2002 at 10:01:20PM +0200, Sam Ravnborg wrote:
> > Now it's testing time..
[...]
You must be missing some of the changes (My first push to bkbits was
incomplete, since I did inadvertently edit Makefile without checking it
out, I do that
On Thu, 3 Oct 2002, Sam Ravnborg wrote:
> > -obj-$(CONFIG_ACPI_INTERPRETER) := $(patsubst %.c,%.o,$(wildcard *.c))
> > +obj-y := dsfield.o dsmthdat.o dsopcode.o dswexec.o dswscope.o \
> > +dsmethod.o dsobject.o dsutils.o dswload.o dswstate.o
>
> Should that have been:
> obj-$(CONFI
On 3 Oct 2002, Xavier Bestel wrote:
> Could you do instead:
>
> include subdir/Makefile
> ?
It's not quite that easy, unfortunately ;(
> This would avoid recursive make, which isn't really a good idea (even if
> it's used widely). Here is a good agument about that:
> http://www.cse.iitb.
On Thu, 3 Oct 2002, Peter Samuelson wrote:
> Which top dir, src or obj? Most end users will expect obj topdir.
> More on that below.
Yes, I think obj topdir is the way to go - and you're right, it can be
made work mostly with vpath and does not need much more.
> > So gcc/ld/.. are now called
Hi,
I'd appreciate to get comments on the appended patch. It's mostly cleanups
and the like, but the interesting part is the last cset, which is actually
fairly small:
14 files changed, 64 insertions(+), 47 deletions(-)
The build process remains recursive, but it changes the recursion
from
On Wed, 2 Oct 2002, Peter Samuelson wrote:
> Almost all kernel makefiles have to include $(TOPDIR)/Rules.make
> explicitly. 3/4 of the time, this is done at the end of the file.
> This patch lets you omit the include line in that case. (You still to
> include Rules.make explicitly if you have s
[Removed l-k Cc]
On Mon, 23 Sep 2002, Jeff Dike wrote:
> [EMAIL PROTECTED] said:
> > The actual executable UML generates is called "linux" anyway, so its
> > Makefile can have its own rule (as for other archs the boot images)
> > which builds "linux" from "vmlinux" using gcc and the link scrip
On Mon, 23 Sep 2002, Jeff Dike wrote:
> The UML build needs a few kbuild changes in order to work with the latest
> stuff.
>
> Since kbuild now enforces the use of the linker script on the vmlinux build,
> UML can't use its old two-stage link, where
> vmlinux is a normal relocatable object
On Mon, 23 Sep 2002, Roman Zippel wrote:
> > I intentionally only printed a message and errored out in this case, and I
> > think that's more useful, particularly for people doing
> >
> > make all 2>&1 > make.log
> >
> > which now may take forever waiting for input.
>
> You should have tried thi
On Sun, 22 Sep 2002, Jeff Garzik wrote:
> Kai Germaschewski wrote:
> > On Sun, 22 Sep 2002, Jeff Garzik wrote:
> >
> >
> >>One cosmetic thing I mentioned to Roman, Config.new needs to be changed
> >>to something better, like conf.in or build.conf or so
On Sun, 22 Sep 2002, Jeff Garzik wrote:
> One cosmetic thing I mentioned to Roman, Config.new needs to be changed
> to something better, like conf.in or build.conf or somesuch.
I agree. (But I'm not particularly good at coming up with names ;)
build.conf is maybe not too bad considering that t
On Sun, 22 Sep 2002, Roman Zippel wrote:
> > I have been working on integrating lkc with kbuild.
> > Here is the result.
>
> Thanks, nice work. :)
Yup, I improved things a bit further.
> > Rules.make
> > - Added infrastructure to support host-ccprogs, in other words
> > support tools written
On Thu, 15 Aug 2002, Peter Samuelson wrote:
> The more I think about it, the more I think the default if_dep should
> do the m-restricting thing. That way:
>
> dep_bool FOO1 BAR BAZ
> dep_mbool FOO2 BAR BAZ
> dep_tristate FOO3 BAR BAZ
>
> is exactly equivalent to
>
> if_dep BAR BAZ
>
On Wed, 14 Aug 2002, Peter Samuelson wrote:
> I've reused the syntax for a dependency line (the tail end of a
> dep_bool / dep_mbool / dep_tristate), like so:
>
> if_dep dependency line
> ...
> endif
Honestly, I do not like this. It's probably the best that can be done in
shell, but I
On Thu, 15 Aug 2002, Roman Zippel wrote:
> > I don't think anyone who actually understands the config system would
> > argue these points, but we are limited by practical constraints to making
> > incremental improvements only.
>
> That's fine with me, but nonetheless I'd really like to know whe
On Wed, 14 Aug 2002, Greg Banks wrote:
> @@ -330,6 +329,5 @@
> 1 CONFIG_ZORRO
> -34 forward-dependancy
> +23 forward-dependancy
> 11 CONFIG_ISDN_CAPI
> 11 CONFIG_PROC_FS
> -11 CONFIG_SOUND_ACI_MIXER
> 1 CONFIG_BLK_DEV_SD
Could you check that
On Wed, 14 Aug 2002, Greg Banks wrote:
> Peter Samuelson wrote:
> >
> > [Greg Banks]
> > > Does "complete" mean all the ports have also made the change and
> > > been merged back?
> > [...]
> > Actually I suspect it would be more like the C99 thing: after the new
> > syntax is added, we start do
On Tue, 13 Aug 2002, Peter Samuelson wrote:
> Here's another one - this should fix the forward dependency between
> CONFIG_SOUND and CONFIG_SOUND_ACI_MIXER, by moving the sound config
> into the "Multimedia" menu - where I think it belongs anyway.
Hmmh, makes sense to me, but there will probably
On Tue, 13 Aug 2002, Greg Banks wrote:
> Kai Germaschewski wrote:
> >
> > But so the change would be a good thing, right? It would make the behavior
> > consistent between all configuration tools,
>
> Sorry, I don't understand what you're getting at. Cu
On Tue, 13 Aug 2002, Peter Samuelson wrote:
> CONFIG_PROC_FS is needed by ISDN hysdn. That's actually in my opinion
> more of a "general kernel facility" than a filesystem. Eh?
Well, the use in hysdn can (and should) die, possibly by adding an
#ifndef CONFIG_PROC_FS
#error This driver won't wo
On Mon, 12 Aug 2002, Greg Banks wrote:
> > > I'm pleased to see that you have preserved those semantics. There
> > > are many places in the corpus where a dep_* lists as a dependency a
> > > variable which is not defined until later, or is only defined in
> > > some architectures, or is never de
On Fri, 31 May 2002, Sam Ravnborg wrote:
> tkparse limit the number of symbols to 2048.
> This patch makes the array dynamic avoiding this problem in the future.
> The problem showed up in one of the powerpc tree's.
Thanks, I'll look at this (and the other patches) and submit it to Linus
(assumi
On Sat, 4 May 2002, Keith Owens wrote:
> An update to 2.5/Documentation/Changes has been submitted. Linus has
> already done 2.5 changes that require make 3.79 features, the Changes
> update is overdue.
Trying to get back to technical issues, which change do you refer to?
(Note that I don't ob
On Fri, 28 Dec 2001, Linus Torvalds wrote:
> On Fri, 28 Dec 2001, Legacy Fishtank 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.
>
> Absolutely. I detest "gcc -MD", exact
[So far, I've generally been trying to keep away from the hot topics, but
I guess it's about time to make that experience. Also, let me add that my
opinion here is of course influenced by the fact that things didn't go the
way I would have liked...]
On Fri, 28 Dec 2001, Keith Owens wrote:
> On
On Mon, 29 Oct 2001, Keith Owens wrote:
> Several Makefile.in files have code like this
>
> ifsel(CONFIG_ISDN_PPP)
> select(CONFIG_ISDN slhc.o)
> endif
How about handling this in the configuration language? I don't know CML2
yet, but I believe it should be easy enough to handle these things
On Thu, 14 Jun 2001, Brad Hards wrote:
> So far so good. The problem comes from introducing the new EHCI, and
> associated refactoring of the common host controller code. The new approach is
> that host controllers will live in a subdirectory (drivers/usb/hcd), and we
> will eventually link in th
On Tue, 29 May 2001, Keith Owens wrote:
> While your rules are good, they only handle the common case of
> compiling a kernel source to a kernel object. That is not really a
> problem, there are several solutions for the common case. I am looking
> at the unusual cases that require explicit use
On Mon, 28 May 2001, Keith Owens wrote:
> My aim is to detect if the command has changed and force the target to
> be rebuilt.
This definitely makes sense. Actually, the entire dependency stuff is
straight forward (but very messy to implement): A target needs to be
rebuild, if the command used
On Fri, 18 May 2001, Eric S. Raymond wrote:
> That being the case, we do face a question of design
> philosophy, expressed as a policy question about how to design
> rulesets. Actually two questions:
>
> 1. When we have a platform symbol for a reference design like MVME147, do
>we stick to i
On Fri, 18 May 2001, Keith Owens wrote:
> That is precisely my problem, it is not done cleanly at the moment.
> We currently have, in roughly this order
>
> global cppflags in top level makefile
> include list from top level makefile
> module/kernel flags from top level makefile
> global
On Fri, 18 May 2001, Keith Owens wrote:
> The distinction between CC and CPP and between [AC]FLAGS and CPPFLAGS
> is very weakly enforced in kbuild. Most code uses CC and [AC]FLAGS,
> even when preprocessing. The extra cflags are almost always
> preprocessor flags, as are [AC]FLAGS_KERNEL.
>
>
On Tue, 1 May 2001, J . A . Magallon wrote:
> On 05.01 Keith Owens wrote:
> >
> > The patch appears to work but is it worth applying now? The existing
> > 2.4 rules work fine and the entire kbuild system will be rewritten for
> > 2.5, including the case you identified here. It struck me as a de
yours yet, but it doesn't need any magic C programs and it
handles all dependencies really right, including modversions. Maybe we can
work together to get the best from both approaches at some point.
On Sun, 15 Apr 2001, Kai Germaschewski wrote:
> On Sat, 14 Apr 2001 [EMAIL PROTECTED] w
this time.
SHORT VERSION:
The attached patch allows to get rid of the "list-multi := ..." lines and
link-rules for multi-part objects in all the Makefiles without breaking
any current Makefile.
-- Forwarded message --
Date: Tue, 24 Apr 2001 15:05:07 +0200 (CEST)
From:
Hi!
I'd like to get some comments on the appended patch. It removes the need
to put explicit link rules for multi-part objects in the individual
Makefiles in the subdirectores and leaves them to Rules.make instead.
I know that 2.5 kbuild will look entirely differently, but I consider this
patch
On Thu, 19 Apr 2001, Eric S. Raymond wrote:
> The following patch cleans dead symbols out of the defconfigs in the 2.4.4pre4
> source tree. It corrects a typo involving CONFIG_GEN_RTC. Another typo
> involving CONFIG_SOUND_YMPCI doesn't need to be corrected, as the symbol
> is never set in thes
On Sat, 14 Apr 2001 [EMAIL PROTECTED] wrote:
> [ohio] /usr/src/linux-2.4.3-kb> make -f Makefile-2.5
> Generating global Makefile
> phase 1
> Unexpected type for kernel file .fs, giving up
> Command exited with non-zero status 1
> 0.01user 0.00system 0:00.01elapsed 100%CPU (0avgtext+0avgdata 0ma
45 matches
Mail list logo
