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 cflags
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 its
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 user
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 the
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 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, exactly because
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
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
(assuming
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 defined.
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 work
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. Currently the behaviour is
consistent between
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 be
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 the
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 where it
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 idependency line/i
...
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, 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
bool
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
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 21 make.log
which now may take forever waiting for input.
You should have tried this first :) :
[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 script. -
I.e.
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
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 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:
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 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:
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-module.o
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 progress.
What people will see
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 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 obj/src tree.
Usage example:
#src
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 ak4xxx.o
29 matches
Mail list logo
