[esr]
> If there were already a library in ths stock Python distribution to
> digest .Xdefaults files I might consider this. Perhaps I'll write
> one. But I'm not going to bulk up the CML2 code with this marginal
> feature.
Wait ... I thought you were just using Python bindings to Tk. Are you
[John Cowan]
> The whole point of CML2 is to make kernel configuration something
> that Aunt Tillie (or a reasonable facsimile thereof) can do, and we
> are all Aunt Tillies from time to time. That includes differing
> standards of readability,
Come on, that's absolutely a red herring. There a
[mec]
> In order to get the information, I had to open up and parse Makefile,
> whichis kinda kludgy.
Yes, but that is only if mconfig was not invoked from 'make'. CML1 and
CML2 don't have this problem.
Peter
___
kbuild-devel mailing list
[EMAIL PRO
[esr]
> > CONFIG_SOUND_YMPCI: arch/ppc/configs/power3_defconfig
>arch/arm/def-configs/footbridge arch/arm/def-configs/rpc arch/arm/def-configs/lart
>arch/arm/def-configs/shark
[jgarzik]
> typo, that should be ...YMFPCI.
Actually it's not a typo (although the fix is the same). The old
"SB-c
Introduced in 2.4.4pre4, I believe. $(export-objs) need not be
conditional, and the if statement was not really correct either,
although in this case it probably worked.
Peter
--- 2.4.4pre6/lib/Makefile~ Mon Apr 23 09:51:17 2001
+++ 2.4.4pre6/lib/Makefile Mon Apr 23 17:11:04 2001
@@
[Peter Samuelson]
> > Introduced in 2.4.4pre4, I believe. $(export-objs) need not be
> > conditional, and the if statement was not really correct either,
> > although in this case it probably worked.
[Tom Rini]
> Er, are you sure changing the test for !"nn" i
[mec]
> > I'm in favor of a single unified list.
[Steven Cole]
> I agree with the above.
Peter
___
kbuild-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/kbuild-devel
[esr]
> > CML2 would probably reject most random configurations for violating
> > some consistency constraint or other. What kind of errors eould we
> > be hunting, anyway?
[kaos]
> Not raw random configurations, the idea is to generate a random
> config then run it through make oldconfig (CM
[esr]
> Besides, right now the configurator has a simple invariant. It will
> only accept consistent configurations
So you are saying that the old 'vi .config; make oldconfig' trick is
officially unsupported? That's too bad, it was quite handy.
Peter
_
[Kai Germaschewski]
> However, I don't think it's hard to verify that my patch works as
> well, it's about ten lines added to Rules.make. It's particularly
> easy to verify that it doesn't change behavior for objects listed in
> $(list-multi) at all.
Yes, we can say this, but people are right t
[Tom Rini]
> Hello all. I've got a question about doing subdirs 'properly'. First,
> what I'm trying to do is cleanup arch/ppc/boot/Makefile. In Linus' tree,
> it's not too bad. But there's a bunch of changes pending, which end up
> leaving the tree looking like this:
>
> # Targets for booti
[Peter Samuelson]
> > bootdirs-$(CONFIG_FOO) += foo
> > bootdirs-$(CONFIG_BAR) += bar
[...]
> > The point here is that you don't use $(subdir-y) for the sub-arch boot
> > dirs.
[Tom Rini]
> Yes, but I want to use subdir- so that deps get done and handled auto
[Peter Samuelson]
> utils-$(CONFIG_FOO) += fooboot
> utils-$(CONFIG_BAR) += barboot bazboot
>
> bootdirs-$(CONFIG_FOO) += foo
> bootdirs-$(CONFIG_BAR) += bar
>
> # Targets for booting
> BOOT_TARGETS = zImage zImage.initrd znetboot znetboot.initrd
> $(BOOT_TAR
[Peter Samuelson]
> > Good point. OK, add the following line:
> >
> > subdir- += $(bootdirs-y) $(bootdirs-n) $(bootdirs-)
[Tom Rini]
> Yes, but is there any compelling reason not to just use subdir- to
> start with?
Having to manually maintain either (a) which s
[kaos]
> select_cond(CONFIG_ISDN CONFIG_ISDN_PPP slhc.o)
>
> Both configs must be selected, either as 'y' or 'm'. The first config
> defined how the object is compiled. I am worried that this might be
> confusing, some users are bound to get the config options in the wrong
> order. Any ideas
[peter]
> >select_cond(CONFIG_ISDN slhc.o CONFIG_ISDN_PPP)
[kaos]
> That is worse, you can select a list of objects, where does the
> second config go?
You can also have a list of CONFIGs, can you not? In which case you
have a parsing problem either way.
Distinguishing between a CONFIG opti
[Peter]
> >You can also have a list of CONFIGs, can you not? In which case you
> >have a parsing problem either way.
[kaos]
> select() takes exactly one CONFIG_, select_cond() takes exactly two.
> No kbuild 2.5 command takes a variable sized list of CONFIGs.
OK, if you say multiple dependent
[kaos]
> >ifeq(,$(findstring n,$(CONFIG_FOO)$(CONFIG_BAR))
> > ifneq(,$(findstring m,$(CONFIG_FOO)$(CONFIG_BAR)))
> ># compile as module
> > else
> ># compile builtin
> > endif
> >endif
>
> That is worse than the existing entries.
I was talking about the Makefile implementation, not
[kaos]
> If you assume that config1 is always boolean then order does not
> matter. If config1 is tristate then order does matter.
>
> config1 config2 objects
> yy y
> ym m
> my y <=== config2 controls
> mm
Current kernel makefile fails to build init/main.o if you use 'make -r'
aka 'make --no-builtin-rules' (make 3.79.1). This fixes it:
--- Makefile~ Sun Nov 18 16:40:49 2001
+++ MakefileSun Nov 18 20:02:19 2001
@@ -333,7 +333,7 @@
$(CC) $(CFLAGS) $(CFLAGS_KERNEL) -DUTS_MACHINE='"$(AR
[I wrote]
> I don't see why we use $* at all -- of the 150 or so instances, it
> looks like they *all* could be replaced with $< or $@. The GNU make
> info page actually deprecates $* except for use with implicit rules.
Oh and hey, look at that. Three of the usages are even buggy.
# see arch/
[kaos]
> On the one hand, new config entries default to 'n' (in .config, but
> not config.out) so forgetting to make *config should be fail safe.
Not always. Remember when CONFIG_PSMOUSE went from tristate to bool
late in 2.1.x? If you had CONFIG_PSMOUSE=m at that point you would get
an unexpe
[C. Slater]
> I was just wondering why rules.cml and symbols.cml are read only,
> even for owner.
Let met guess, ESR exported them from RCS and didn't chmod before
tarring them up.
I agree - this should be fixed. (Not that it will matter once the
patch is in the kernel.)
Peter
__
[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 paralleli
[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
[esr]
> > * The `vitality' flag is gone from the language. Instead, the
> > autoprober detects the type of your root filesystem and forces
> > its symbol to Y.
[Russell King]
> This seems like a backwards step. What's the reasoning for breaking
> the ability to configure the
[esr]
> The version I just released does exactly that. Well, not exactly; it
> actually looks at fstab -- /proc/mounts gives you '/dev/root' rather
> than a physical device name in the root entry.
/etc/fstab is hardly guaranteed to be accurate either. The kernel
mounts the root device based on
Forgot this point earlier..
[esr]
> > > The version I just released does exactly that. Well, not exactly; it
> > > actually looks at fstab -- /proc/mounts gives you '/dev/root' rather
> > > than a physical device name in the root entry.
IMHO you should still use /proc/mounts to determine the r
[Brendan J Simon]
> OK. I saw the instructions. kbuild-2.5-2.4.17-1 says to patch
> against the linus-2.4.17 kernel where as kbuild-2.5-2.4.16-ppc-2 says
> to patch against the marcelo kernel. I did a search on google and
> found Marcelo's directory of kernels. Are these specially patched
> k
[A Guy Called Tyketto]
> Just an FYI.. when one runs 'make xconfig', and goes to request help
> on a certain option given, a message comes up:
Known issue. Configure.help has been split up, menuconfig and xconfig
don't know this yet. If you want to fix it, feel free. It's probably
no
[Eric S. Raymond]
> I'm not ignoring your point at all. But saying "don't make policy
> changes" is easy to do, knowing where the boundary between "policy"
> and "design bugs" falls is rather harder. I'm not going to refrain
> from fixing design bugs because some people might think they are
> p
[[EMAIL PROTECTED]]
> I want to know where all i have to make entries in the source code of
> linux so that while building the Linux kernel i can include my device
> driver in the kernel.
There are files in many of the directories of the kernel called
'Config.in'. Find an appropriate one and ad
[kaos]
> Can anybody do an up to date set of Makefile.in files for 2.4.18 and
> 2.5.5?
Working on it ... hope to have something in a few hours, unless someone
beats me to it.
Peter
___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourcef
[kaos]
> > Can anybody do an up to date set of Makefile.in files for 2.4.18
> > and 2.5.5?
[Peter Samuelson]
> Working on it ... hope to have something in a few hours, unless
> someone beats me to it.
OK, I have a first cut of the makefiles for 2.5.6pre1. I have done
some
[Peter Samuelson]
> I'm working on the 2.4.18 version (Keith's latest is -pre1), unless
> someone else gets one out first..
Done, see http://wire.cadcamlab.org/misc/kbuild/ .
This was much easier than 2.5 as it didn't have ALSA. (:
I will try to find time to test all thi
[Thomas Duffy]
> I don't know if you already figured it out, but there were two typos
> in your new 2.4.18 Makefile.in patch. Here is a patch to fix
> those...
Yeah, I sent them on to Keith awhile back. They're obvious enough,
since kbuild-2.5 catches them at "compile" time
Thanks,
Peter
[Sebastian Heidl]
> > It's signed. Just pipe it through gpg with Keiths public key.
[Mike Fedyk]
> Signed means that there is a checksum at the bottom that you can
> verify with gpg/pgp to see if the message was tampered with, but the
> text itself it still in ascii and not encoded.
Not that
[Dominik Brodowski]
> So my suggestion is that in a first step the Makefile.in in each
> directory could be parsed to the existing form of Makefiles[*], with
> the rest of the build system staying the same. This Makefile.in ->
> Makefile (per directory) parsing could be done as first step of "mak
[CCs trimmed]
[Sam Ravnborg]
> > Obviously the kernel build system should work for everyone irrespective
> > of the SCM system in use. This put at least the following demands:
> > 1) Separate OBJ and SRC tree
> > 2) That kbuild does not touch any files in the SRC tree
Agreed. It lo
[Greg Banks]
> I think the problem of Makefile bits in shadow trees is really quite
> difficult. Keith's solution of pre-processing Makefiles and
> Makefile.appends from all the shadow trees into a combined Makefile
> doesn't handle all the cases but is the best attempt I've seen so
> far.
Agre
[Sam Ravnborg]
> > This does not stop any attemp to make a simple wrapper that
> > creates and maintain a BUILD_TREE.
> > To check timestamps and link accordinly should not take too much
> > time, at least not at the second run.
[Greg Banks]
> Ok, why don&#x
[I wrote]
> (cd $s; find * -type d) | xargs mkdir -p;
> (cd $s;
>exec find * \( -type d -exec mkdir \{} \; \) -o \
> \( -type f ! -name \*.prepend ! -name \*.append -print \) ) |
> while read f; do
This is redundant - the second mkdir is not needed.
Should be:
(cd $s; exec fi
[Keith Owens]
> prepend/append are logical wrappers, the order is prepend top to
> bottom, base file, append bottom to top. This must be done over all
> source trees.
I think my hack wrapper does that already.
> prepend/append entries in shadow trees below the base version of a
> file must be
t restrict the input range. Any dependency which expands to
+"m" restricts the input range to "m" or "n". Any dependency which
+expands to an empty value is ignored. Any dependency which expands to
+"n", or any other value, restricts the input range to "n&q
[Peter Samuelson]
> > !y == n
> > !m == n
> > !n == y
[Roman Zippel]
> I would define !m as m, e.g. it would allow
>
> dep_tristate "" CONFIG_OLD !$CONFIG_NEW
> dep_tristate "" CONFIG_NEW !$CONFIG_OLD
You know, that never even occurred to
[Russell King]
> Erm, !n == n ???
Duh. I need some serious sleep. That wasn't the only semantically
significant typo in my post, only the worst. Obviously, !n == y.
Peter
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek hea
[Greg Banks]
> I like the basic idea here, and I'm pleased that someone has the
> courage to tackle some of the brokenness of the kconfig language (if
> only because it will provide me with a precedent when I try to
> submit some of my patches ;-).
Thanks for the feedback. (:
> > This applies t
[I wrote]
> > This stuff is trivial enough, and easy enough to test, that I
> > think it could go in 2.4, yes.
[Greg Banks]
> I think you're underestimating the Gordian knot that is the CML1 corpus.
Yes, very possibly.
> To pick an example, in 2.5.29 drivers/ide/Config.in:17 is
>
>dep_t
[Roman Zippel]
> with the latest modifications this can be written as:
>
> dep_tristate NEW !OLD
> dep_tristate OLD !NEW
>
> This still has the back reference and you have to run 'make config'
> twice to change NEW from n to y.
I don't see this as a big problem. Most people don't use the bare
[Greg Banks]
> Ah. If you're willing to knowingly feed Linus with patches that
> break current config behaviour, then OK we have a way to proceed.
Things knowingly break in 2.5 all the time. I for one have no problem
with this. Especially since the breakage is so easy to pinpoint,
thanks to y
[Greg Banks]
> Ok, here it is.
Thanks again. It will take some time to double-check what I termed
the "false positives", but now you've reduced the "interesting cases"
down to 30 symbols.
(BTW, the format is great - I can use 'M-x compile' and 'M-x
next-error' and Emacs pulls up files and li
[Sam Ravnborg]
> How about extending the language (side effect) to automagically
> append (EXPERIMENTAL) or (OBSOLETE) to the menu line, if dependent
> on those special tags?
I've thought about that too. Menuconfig already has magic code to
append ' (NEW)' if it hasn't seen a symbol before.
Yo
FIG_FOO $CONFIG_BAR vs.
> b) dep_bool ' Blah' CONFIG_FOO CONFIG_BAR
>
> (the latter proposed by Peter Samuelson)
>
> I see the following:
> b) needs a large scale patch through all Config.in's. OTOH, it can be
> done step by step, only changin
[I wrote]
> > sed '/dep_/s/ \$CONFIG_/ CONFIG_/g' is quite effective. In any
> > case it is not hard to support both syntaxes - once the transition
> > is complete,
[Greg Banks]
> Does "complete" mean all the ports have also made the change and
> been merged back?
Either that, or, Linus gets
[Greg Banks]
> define_bool CONFIG_QUUX y
>
> bool 'Set this symbol to ON' CONFIG_FOO
>
> if [ "$CONFIG_FOO" = "y" ]; then
> bool 'Here QUUX is a query symbol' CONFIG_QUUX
> fi
It's (somewhat) well-known that things tend to fly apart when you try
to redefine a symbol. I d
[Greg Banks]
[I wrote]
> > (BTW, the format is great - I can use 'M-x compile' and 'M-x
> > next-error' and Emacs pulls up files and lines for me.)
>
> This is not a coincidence.
Indeed not - if you hadn't already used that format I would have
munged it. Grew up on gcc, so this is my favorit
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.
The big loser here is ARM - it no longer suppresses the sound card
question for the appropriate bo
[I 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.
[Kai Germaschewski]
> Hmmh, makes sense to me, but there will probably
[Greg Banks]
> warning:drivers/parport/Config.in:14:forward declared symbol "CONFIG_SERIAL"
>compared ambiguously to "n"
> warning:drivers/parport/Config.in:14:forward reference to "CONFIG_SERIAL"
> warning:drivers/parport/Config.in:15:forward reference to "CONFIG_SERIAL"
>
>
> warning:drivers
[Sam Ravnborg]
> Where comes the requirement that we shall keep the existing shell
> based config parsers?
I don't make that argument - mconfig is the superior solution by far -
but it is certainly the path of least resistance.
As pertains to CONFIG_EXPERIMENTAL and " (EXPERIMENTAL)", it *is*
drivers/char/Config.in still has a complete copy of agp/Config.in.
It's an exact cut-n-paste - the md5sums even match. (:
--- 2.5.31/drivers/char/Config.in~ 2002-08-08 22:43:28.0 -0500
+++ 2.5.31/drivers/char/Config.in 2002-08-14 17:25:20.0 -0500
@@ -173,21 +173,7 @@
ction?
Peter
--- 2.5.31/scripts/Menuconfig 2002-06-09 00:27:32.0 -0500
+++ 2.5.31w/scripts/Menuconfig 2002-08-14 21:00:27.0 -0500
@@ -73,7 +73,10 @@
# - Support for multiple conditions in dep_tristate().
# - Implemented new functions: define_tristate(), define_int(), define_hex(),
# define
[Greg Banks]
> > > > + dep_tristate ' I2C bit-banging interfaces' CONFIG_I2C_ALGOBIT $CONFIG_I2C
> > >
> > > Are you sure want this one there?
> >
> > I didn't like it either, but it's needed in a couple odd places. What
> > would you suggest - moving the whole i2c menu up?
>
> Not all the
[Brendan J Simon]
> > Either if_dep, else_dep and end_dep _or ifdep, elsedep, enddep.
I like it. My original if_dep was ifdep, but I thought people would
mistake it for the common verb 'ifdef' and misspell it that way. So I
vote for the _s.
[Greg Banks]
> Yes, the _s should be consistent.
Greg, in regards to another question you had - no I don't think there
is value in having a variant if statement that treats 'm' differently.
You can already get the same effect by using 'CONFIG_FOO=y' or
'CONFIG_FOO=m' instead of plain 'CONFIG_FOO'.
You are much better than I at finding examples
[Giacomo A. Catenazzi]
> I don't like calling it "or"... It is error prone because it is a non
> binary system,
> thus can confuse the lazy developers.
I had to call it something. I for one think 'or' is quite intuitive
here. If you insist that OR can only be done on binary values, think
of '
[Kai Germaschewski]
> Honestly, I do not like this. It's probably the best that can be
> done in shell, but I think it's ugly and not intuitive.
I accept that it is not pretty. But unless we can switch to mconfig
or gcml2 or some other static parser for everything, we will need
shell-parsable s
[Greg Banks]
> I was thinking that with your proposed syntax we'd have a large
> level of compatibility in both syntax and semantics between "if_dep"
> and "dep_bool", much more so than with "if" and "dep_bool"
As you said the other day, "This is not a coincidence." (:
But technically, if_dep c
[John Alvord]
> I've been puzzling about this problem and the CML2 trainwreck.
>
> Maybe we can used advanced tools to remove the many bugs and
> inconsistancies and then switch to a better config tool.
That's exactly what we're trying to do. Greg has the advanced
consistency checking, and I'v
[Greg Banks]
> Sure, but with something like "if_dep" <-> "dep_bool" and "if_mdep"
> <-> "dep_mbool" there exists a simple and bidirectional textual
> rearrangement which completely preserves semantics, to go between
> using the if and using the dep_*. This means people can safely
> switch betwe
[Kai Germaschewski]
> Seeing it from that point of view, it may actually turn into
> something which can agree with much more easily.
Great! I've been hoping for your support - not only because I respect
your judgment, but also because Linus takes patches from you. (:
> Maybe it actually suffi
[Roman Zippel]
> I really hate to spoil the fun
(:
> but could someone explain to me, why this is necessary? What
> problems does that fix?
It's not necessary, technically - it doesn't directly fix any bugs.
It falls under "cleanup", and as such, it is supposed to make bugs
harder to write an
[I wrote]
> I've come up with syntax I think I'm happy with.
Thank you one and all for all the discussion and suggestions for
improvement on my proposals. I've incorporated a lot of feedback.
I know I promised to try and come up with a working prototype
including some Config.in files, but some
[Kai Henningsen]
> Incidentally, wouldn't it make sense to use "dep_if" instead of "if_dep"?
Yes, probably. I'll go ahead and change it in my tree, unless anyone
objects violently.
Peter
---
This sf.net email is sponsored by: OSDN - Tired o
[Greg Banks]
> Ok, we need to be a little bit careful about semantics here, or
> there is going to be issues converting the existing corpus.
Agreed.
> Currently the "if" syntax and dependencies are not the same thing;
> the "if" condition is purely a visibility limit, and deps are both
> value
[I wrote]
> > I guess I wasn't quite clear: my current implementation is both
> > visibility + value, not visibility only (like current if [ ]) or
> > value only (like an earlier discussion of dep_if).
[Greg Banks]
> Aha. I think you're going to be arguing uphill to get it in.
Could be. Per
[Greg Banks]
> There are other ways to use "if" statements not covered by these two
> cases, for example a couple of minutes of manual scanning reveals...
>
> int ' default tagged command queue depth' CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS 8
> if [ "$CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS" = "0" ]; th
[Greg Banks]
> Have you assessed the impact of making the visibility guard
> (CONFIG_HOTLPLUG in this example) also a value limit for the symbols
> defined in the source'd file?
Not an issue, as CONFIG_HOTPLUG is a bool, and I see no conceivable
reason it should become a tristate.
But yes, when
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 special make rules.)
As a positive side effect, we
[Kai Germaschewski]
> I've been thinking about doing something like this a couple of
> times. The reasons I didn't actually do it yet was that include
> $(TOPDIR)/Rules.make was kind of a separator between automatically
> handled stuff and additional hand-made rules for special cases.
Well, OK -
Random thoughts. I haven't actually tested the patch yet, so feel
free to ignore me. (:
[Kai Germaschewski]
> i.e. the current working directory remains the top dir for all
> times.
Which top dir, src or obj? Most end users will expect obj topdir.
More on that below.
> So gcc/ld/.. are now
[Sam Ravnborg]
> > +ifdef list-multi
> > +$(warning kbuild: list-multi ($(list-multi)) is obsolete in 2.5. Please fix!)
> > +endif
> Since kbuild no longer support list-multi this should be $(error )
Except that it is harmless. list-multi is a hint which the kbuild
system no longer needs.
[Brendan J Simon]
> What is the status of kbuild with respect to getting into the kernel
> proper ?
> Is it going to get into the linus kernel source tree ??
At this point it doesn't seem likely. Of the rich feature set Keith
produced, Kai Germaschewski has managed to replicate the most
compel
[Brendan J Simon]
> Is there a site that documents the changes the Kai has made or is
> making ?
Well, there's http://www.??.kernel.org/pub/linux/kernel/v2.5/ChangLog-*,
search for "kai@". He seems to have started in 2.5.7.
Off the top of my head, the main kbuild2.5 features 2.5.40 *doesn't*
h
[Brendan J Simon]
> Thanks for that information. Looks like Kai's work will/may
> eventually do what I want but when will it be mainstream, that is the
> question.
If by "mainstream" you mean "in 2.4", probably never. There is just no
motivation to backport it, and I doubt Marcelo would accept
[Roman Zippel]
> The problem is that the config syntax will continue to evolve and
> currently I prefer to keep the library close to the matching config
> files.
> I think I can keep the basic structure constant, but new options will be
> added, so IMO it's more likely that a front end works with
Now that O_TARGET is actually illegal...
--- Rules.make~ 2002-10-16 13:37:41.0 -0500
+++ Rules.make 2002-10-16 14:59:54.0 -0500
@@ -154,7 +154,7 @@
# ---
fastdep: $(subdir-ym)
- @/bin/true
+
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
CC (M) partial-module.o
LD built-in.o
[I wrote]
> +quiet_modtag = $(if $(findstring $@,$(obj-m)),[M],$(if $(findstring
>$@,$(real-objs-m)),(M), ))
Actually s/findstring/filter/g is a bit cleaner.
Peter
---
This SF.net email is sponsored by: ApacheCon, November 18-21 in
Las Veg
[Sam Ravnborg]
> Nice.
Thanks.
> > Does not support CPP or CC -S ... do those even work?
> Could you please elaborate - what do you impose by CPP and CC -s?
> Maybe it just too late in my timezone...
I'm talking about the built-in rules for .c->.i (preprocessing), .S->.s
(preprocessing), and .c
[Kai Germaschewski]
> This looks generally looks okay to me, I don't like the subtle
> difference between stand-alone and partial module, though, probably
> nobody can remember that, anyway ;) And there is really no difference
> in the command line, so why print something different.
The idea was
[Kai Germaschewski]
> Well, it's not that my life depends on it ;)
Heh.
> But I see the non-verbose mode as an abbreviated view of what
> happens, and normally you cannot see the difference between module or
> part of module, so it appears inconsistent to have that distinction
> in the short vie
[Kai Germaschewski]
> I completely agree, though it weakens my argument about consistency ;)
Heh.
> 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
Note: this question really belongs on <[EMAIL PROTECTED]>.
[Pannaga Bhushan]
> I am looking for a setup where I need to have a certain amount
> of data always available to the kernel. The size of data I am looking
> at is abt 40MB(preferably, but I will settle for 20MB too) . So the
> nor
[Petr Baudis]
> Can't say anything about the C++ stuff, but the second user of shared
> libraries is going to be lxdialog - hopefully this evening already,
> in my patches (it already works, I'm only cleaning out few details
> now; lxdialog + mconf is also user of both these extensions).
What is
[Peter Samuelson]
> > Basically, what I'm saying is, I see no need for the existing .so in
> > the kernel build, much less another one. Static libraries are ever so
> > much easier to manage.
[Roman Zippel]
> If you want to limit people to the config tools in the ke
[Peter Samuelson]
> > Huh? I don't get it. How is a shared library any better than a static
> > library in this regard? I'm pondering the traditional advantages of
> > shared libraries, and I cannot think of a single one that matters here.
[Roman Zippel]
>
[Roman Zippel]
> New features will be added and only the parser that comes with the kernel
> will understand them. It's less likley that the library API will change.
Even if this is true - I'll grant you that it may be - let the vendor
package /usr/bin/qconf as a shell script that links /usr/lib
[Roman Zippel]
> If your build environment doesn't support shared libraries, you can
> easily generate a static library instead and link against it
> yourself, like you described, but it's no reason to deny the
> convenience to working environments.
Yeah, but until I do, I can't even run 'make ol
[Petr Baudis]
> I'm a bit lost here - the kernel uses tons of gcc extensions - how is
> another compiler supposed to understand them? And if it is
> specifically extended to understand them, isn't it likely that it'll
> understand the -shared switch in gcc-like way as well?
There is a difference
1 - 100 of 103 matches
Mail list logo
