The change below is shitting i386 defconfig (as well as my usual config)
build log with warnings:
CC init/main.o
`-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.
`-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.
gcc is 4.1.1.
------------------
$ git-cat-file commit 5de043f4bd11a9e0a3e8daec7d1905da575a76b7
tree 1cdafacd6a0f6e12bd5b88d9031a6130169ca868
parent f6112ec27a8f0eee6c5a996f65c7bfd9457d9f85
author Oleg Verych <[email protected]> 1170724701 +0100
committer Linus Torvalds <[email protected]>
1170801049 -0800
[PATCH] kbuild: improve option checking, Kbuild.include cleanup
GNU binutils, root users, tmpfiles, external modules ro builds must
be fixed to do the right thing now.
Hi,
On Wed, 7 Feb 2007, Alexey Dobriyan wrote:
> The change below is shitting i386 defconfig (as well as my usual config)
> build log with warnings:
>
> CC init/main.o
> `-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.
> `-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.
>
> gcc is 4.1.1.
>
> ------------------
> $ git-cat-file commit 5de043f4bd11a9e0a3e8daec7d1905da575a76b7
> tree 1cdafacd6a0f6e12bd5b88d9031a6130169ca868
> parent f6112ec27a8f0eee6c5a996f65c7bfd9457d9f85
> author Oleg Verych <[email protected]> 1170724701 +0100
> committer Linus Torvalds <[email protected]>
> 1170801049 -0800
>
> [PATCH] kbuild: improve option checking, Kbuild.include cleanup
>
> GNU binutils, root users, tmpfiles, external modules ro builds must
> be fixed to do the right thing now.
Linus, please revert. Thanks.
bye, Roman
On Wed, Feb 07, 2007 at 06:47:15PM +0100, Roman Zippel wrote:
> Hi,
>
> On Wed, 7 Feb 2007, Alexey Dobriyan wrote:
>
> > The change below is shitting i386 defconfig (as well as my usual config)
> > build log with warnings:
> >
> > CC init/main.o
> > `-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.
> > `-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.
> >
> > gcc is 4.1.1.
> >
> > ------------------
> > $ git-cat-file commit 5de043f4bd11a9e0a3e8daec7d1905da575a76b7
> > tree 1cdafacd6a0f6e12bd5b88d9031a6130169ca868
> > parent f6112ec27a8f0eee6c5a996f65c7bfd9457d9f85
> > author Oleg Verych <[email protected]> 1170724701 +0100
> > committer Linus Torvalds <[email protected]>
> > 1170801049 -0800
> >
> > [PATCH] kbuild: improve option checking, Kbuild.include cleanup
> >
> > GNU binutils, root users, tmpfiles, external modules ro builds must
> > be fixed to do the right thing now.
>
> Linus, please revert. Thanks.
Roman, while it went so fast to Linus, i didn't expect that, let me
try to fix all this with this little patch.
---
Subject: [patch] kbuild, Kbuild.include: avoid using spaces in call arguments
Do not use whitespace in arguments of functions in makefiles, as
they propagate further without notice. Thus we get
+ echo ' y'
instead of
+ echo y
Fix misleading comments.
Signed-off-by: Oleg Verych <[email protected]>
---
Whitespaces in makefiles are PITA. But i've learnt this already.
scripts/Kbuild.include | 40 ++++++++++++++++++++--------------------
1 file changed, 20 insertions(+), 20 deletions(-)
Index: linux-2.6.20/scripts/Kbuild.include
===================================================================
--- linux-2.6.20.orig/scripts/Kbuild.include 2007-02-07 22:54:01.814467250 +0100
+++ linux-2.6.20/scripts/Kbuild.include 2007-02-07 22:54:17.099422500 +0100
@@ -58,5 +58,5 @@ endef
# checker-shell
-# Usage: option = $(call checker-shell, $(CC)...-o $$OUT, option-ok, otherwise)
+# Usage: option = $(call checker-shell,$(CC)...-o $$OUT,option-ok,otherwise)
# Exit code chooses option. $$OUT is safe location for needless output.
define checker-shell
@@ -75,21 +75,21 @@ endef
# as-option
-# Usage: cflags-y += $(call as-option, -Wa$(comma)-isa=foo,)
-as-option = $(call checker-shell, \
- $(CC) $(CFLAGS) $(1) -c -xassembler /dev/null -o $$OUT, $(1), $(2))
+# Usage: cflags-y += $(call as-option,-Wa$(comma)-isa=foo,)
+as-option = $(call checker-shell,\
+ $(CC) $(CFLAGS) $(1) -c -xassembler /dev/null -o $$OUT,$(1),$(2))
# as-instr
-# Usage: cflags-y += $(call as-instr, instr, option1, option2)
-as-instr = $(call checker-shell, \
- printf "$(1)" | $(CC) $(AFLAGS) -c -xassembler -o $$OUT -, $(2), $(3))
+# Usage: cflags-y += $(call as-instr,instr,option1,option2)
+as-instr = $(call checker-shell,\
+ printf "$(1)" | $(CC) $(AFLAGS) -c -xassembler -o $$OUT -,$(2),$(3))
# cc-option
-# Usage: cflags-y += $(call cc-option, -march=winchip-c6, -march=i586)
-cc-option = $(call checker-shell, \
- $(CC) $(CFLAGS) $(if $(3),$(3),$(1)) -S -xc /dev/null -o $$OUT, $(1), $(2))
+# Usage: cflags-y += $(call cc-option,-march=winchip-c6,-march=i586)
+cc-option = $(call checker-shell,\
+ $(CC) $(CFLAGS) $(if $(3),$(3),$(1)) -S -xc /dev/null -o $$OUT,$(1),$(2))
# cc-option-yn
-# Usage: flag := $(call cc-option-yn, -march=winchip-c6)
-cc-option-yn = $(call cc-option, "y", "n", $(1))
+# Usage: flag := $(call cc-option-yn,-march=winchip-c6)
+cc-option-yn = $(call cc-option,"y","n",$(1))
# cc-option-align
@@ -99,5 +99,5 @@ cc-option-align = $(subst -functions=0,,
# cc-version
-# Usage gcc-ver := $(call cc-version, $(CC))
+# Usage gcc-ver := $(call cc-version,$(CC))
cc-version = $(shell $(CONFIG_SHELL) $(srctree)/scripts/gcc-version.sh $(CC))
@@ -108,6 +108,6 @@ cc-ifversion = $(shell [ $(call cc-versi
# ld-option
# Usage: ldflags += $(call ld-option, -Wl$(comma)--hash-style=both)
-ld-option = $(call checker-shell, \
- $(CC) $(1) -nostdlib -xc /dev/null -o $$OUT, $(1), $(2))
+ld-option = $(call checker-shell,\
+ $(CC) $(1) -nostdlib -xc /dev/null -o $$OUT,$(1),$(2))
######
@@ -121,13 +121,13 @@ build := -f $(if $(KBUILD_SRC),$(srctree
# add original to the end
addtree = $(if \
- $(filter-out -I/%, $(1)), $(patsubst -I%,-I$(srctree)/%,$(1))) $(1)
+ $(filter-out -I/%,$(1)),$(patsubst -I%,-I$(srctree)/%,$(1))) $(1)
# Find all -I options and call addtree
-flags = $(foreach o,$($(1)), \
- $(if $(filter -I%,$(o)), $(call addtree, $(o)), $(o)))
+flags = $(foreach o,$($(1)),\
+ $(if $(filter -I%,$(o)),$(call addtree,$(o)),$(o)))
# echo command.
# Short version is used, if $(quiet) equals `quiet_', otherwise full one.
-echo-cmd = $(if $($(quiet)cmd_$(1)), \
+echo-cmd = $(if $($(quiet)cmd_$(1)),\
echo ' $(call escsq,$($(quiet)cmd_$(1)))$(echo-why)';)
@@ -136,5 +136,5 @@ cmd = @$(echo-cmd) $(cmd_$(1))
# Add $(obj)/ for paths that are not absolute
-objectify = $(foreach o,$(1), $(if $(filter /%,$(o)), $(o), $(obj)/$(o)))
+objectify = $(foreach o,$(1),$(if $(filter /%,$(o)),$(o),$(obj)/$(o)))
###
Hi,
On Wed, 7 Feb 2007, Oleg Verych wrote:
> > Linus, please revert. Thanks.
>
> Roman, while it went so fast to Linus, i didn't expect that, let me
> try to fix all this with this little patch.
Sorry, it needs more changes, the patch simply wasn't ready.
bye, Roman
On Thu, 8 Feb 2007 00:34:50 +0100 (CET) Roman Zippel wrote:
> Hi,
>
> On Wed, 7 Feb 2007, Oleg Verych wrote:
>
> > > Linus, please revert. Thanks.
> >
> > Roman, while it went so fast to Linus, i didn't expect that, let me
> > try to fix all this with this little patch.
>
> Sorry, it needs more changes, the patch simply wasn't ready.
Can you be more explicit? and then it should get some time
in -mm, hopefully.
Thanks,
---
~Randy
On Thu, 8 Feb 2007, Roman Zippel wrote:
>
> Sorry, it needs more changes, the patch simply wasn't ready.
One problem I find very problematic with all the Kbuild setup is that
people tend to be very quiet about any build issues until they simply go
in.
Things don't "get ready" on their own. In other areas, people comment on
why they don't like patches. In Kbuild, for some reason, we often seem to
have this situation where people don't react at all.
Sam is great about maintaining the kernel build stuff most of the time,
but because it's clearly a "secondary" thing, there tends to be some
periods when nothing happens. Which is problematic for me..
So I end up in a situation where I just basically will apply the patches
just becauseif I don't, nothing ever happens. The good news is that _once_
I apply them, people will usually notice problems and send in fixes fairly
quickly. But this particular email was NOT useful, for example. "needs
more changes" is the epitome of a "not useful" comment.
I notice that Kai should probably have been Cc'd, and quite possibly
wasn't. So I added him now.
In the meantime, I've applied the fixup patch. And more specific problem
reports or patches are welcome.
Linus
Hi,
On Wed, 7 Feb 2007, Randy Dunlap wrote:
> > > > Linus, please revert. Thanks.
> > >
> > > Roman, while it went so fast to Linus, i didn't expect that, let me
> > > try to fix all this with this little patch.
> >
> > Sorry, it needs more changes, the patch simply wasn't ready.
>
> Can you be more explicit? and then it should get some time
> in -mm, hopefully.
I did already. It needs to be splitted, lose the symlink stuff and be more
careful with whitespace. It probably could use a better name than
checker-shell, e.g. autoconf calls this TRY_RUN, so something like this.
bye, Roman
Hi,
On Wed, 7 Feb 2007, Linus Torvalds wrote:
> So I end up in a situation where I just basically will apply the patches
> just becauseif I don't, nothing ever happens. The good news is that _once_
> I apply them, people will usually notice problems and send in fixes fairly
> quickly. But this particular email was NOT useful, for example. "needs
> more changes" is the epitome of a "not useful" comment.
The patch was already in -mm and being worked on...
> In the meantime, I've applied the fixup patch. And more specific problem
> reports or patches are welcome.
_Please_ revert completely and wait for Andrew to send it via -mm, when
it's ready.
bye, Roman
On Thu, Feb 08, 2007 at 01:00:44AM +0100, Roman Zippel wrote:
> Hi,
>
> On Wed, 7 Feb 2007, Randy Dunlap wrote:
>
> > > > > Linus, please revert. Thanks.
> > > >
> > > > Roman, while it went so fast to Linus, i didn't expect that, let me
> > > > try to fix all this with this little patch.
> > >
> > > Sorry, it needs more changes, the patch simply wasn't ready.
> >
> > Can you be more explicit? and then it should get some time
> > in -mm, hopefully.
>
> I did already. It needs to be splitted,
i did that patch for ultrasonic testers of Linus's tree. Shame on me,
because, i was sure, that... whatever. This is where i thought, that i
almost understand it all, but another huge level of complexity was
revealed (even it's just a whitespace ;).
I've started to split changes,
> lose the symlink stuff and be more careful with whitespace. It probably
> could use a better name than checker-shell, e.g. autoconf calls this
> TRY_RUN, so something like this.
but i can't understand you, Roman, against:
-- `find | sort' in localversion (i insist on split between paths and
files)
-- symlinks to /dev/null in option checking -- isn't it better to not
have any (though cached) access to files on filesystem, instead of to
/dev/null? cont.:
Anyway, i think, it's better than before, that now all is one place, and
can be named as you wish. Any further changes, like common `tmp'
directory are easy to fix. Readable form, easy to test/debug:
add `-x' to `set' or `echo >gcc-checks.txt', and you will get output, you wish.
IMHO it's good, while arch specific gcc checking already done (:
I wish to have more people to work on this (even with just comments),
because "Kbuild.include" was only first step to reduce bloated top
Makefile. Since then, it seems, Sam have more important things to do.
If further work is useful, i will be glad if you think so.
Thanks.
____
Hi,
On Thu, 8 Feb 2007, Oleg Verych wrote:
> -- `find | sort' in localversion (i insist on split between paths and
> files)
make has dedicated functions for this.
> -- symlinks to /dev/null in option checking -- isn't it better to not
> have any (though cached) access to files on filesystem, instead of to
> /dev/null? cont.:
symlinks are not much else than special files.
> I wish to have more people to work on this (even with just comments),
> because "Kbuild.include" was only first step to reduce bloated top
> Makefile. Since then, it seems, Sam have more important things to do.
The problem is that you mix multiple changes into a single patch, but
since kbuild is very central part that puts everything together, I don't
think it's bad idea to be more conservative, especially if you just start
to work on it.
bye, Roman
On Thu, Feb 08, 2007 at 03:05:41AM +0100, Roman Zippel wrote:
> Hi,
>
> On Thu, 8 Feb 2007, Oleg Verych wrote:
>
> > -- `find | sort' in localversion (i insist on split between paths and
> > files)
>
> make has dedicated functions for this.
I think, "make" (even whatever shiny new) that particular problem can't
handle. Regexp on *file name* is needed, while PATH must be untouched.
That what i meant with spliting tasks. Stripping strings of wildcards
by "make dedicated functions" is ugly, IMHO.
Also, what do you think, if someone (very unlikely) will add port of build
system to something different? Clear logic for a "rule" is there, one can
easily make whole `include/config/kernel.release' with that.
> > -- symlinks to /dev/null in option checking -- isn't it better to not
> > have any (though cached) access to files on filesystem, instead of to
> > /dev/null? cont.:
>
> symlinks are not much else than special files.
IMHO, cheap I/O. Yes, that isn't a big benefit, but i don't see anything
against, except, probably, filesystems without support of symlinks.
> > I wish to have more people to work on this (even with just comments),
> > because "Kbuild.include" was only first step to reduce bloated top
> > Makefile. Since then, it seems, Sam have more important things to do.
>
> The problem is that you mix multiple changes into a single patch,
Yes, from whitespace-issue point of view, that was a huge change (:,
> but since kbuild is very central part that puts everything together,
and patch set didn't make a single release of -mm tree (:
> I don't think it's bad idea to be more conservative, especially if you
> just start to work on it.
.... alone. I think it will be OK, Linus is with us!
Thanks, Roman.
____
On Wed, 7 Feb 2007 15:52:54 -0800 (PST) Linus Torvalds <[email protected]> wrote:
> On Thu, 8 Feb 2007, Roman Zippel wrote:
> >
> > Sorry, it needs more changes, the patch simply wasn't ready.
>
> One problem I find very problematic with all the Kbuild setup is that
> people tend to be very quiet about any build issues until they simply go
> in.
>
> Things don't "get ready" on their own. In other areas, people comment on
> why they don't like patches. In Kbuild, for some reason, we often seem to
> have this situation where people don't react at all.
>
> Sam is great about maintaining the kernel build stuff most of the time,
> but because it's clearly a "secondary" thing, there tends to be some
> periods when nothing happens. Which is problematic for me..
>
> So I end up in a situation where I just basically will apply the patches
> just becauseif I don't, nothing ever happens. The good news is that _once_
> I apply them, people will usually notice problems and send in fixes fairly
> quickly. But this particular email was NOT useful, for example. "needs
> more changes" is the epitome of a "not useful" comment.
Yes, kbuild is a bit of a problem at present.
I'm sitting on these:
search-a-little-harder-for-mkimage.patch
make-mkcompile_h-use-lang=c-and-lc_all=c-for-cc-v.patch
add-mailmap-for-proper-git-shortlog-output.patch
qconf-immediately-update-integer-and-string-values-in-xconfig-display-take-2.patch
qconf-relocate-search-command.patch
qconf-fix-showing-help-info-on-failed-search.patch
qconf-back-button-behaviour-normalization.patch
kbuild-remove-references-to-deprecated-prepare-all-target.patch
new-toplevel-target-headers_check_all.patch
But I'm not sure that anyone has reviewed them much.
I'll probably just push 'em and see what happens. They seem to work.
Hallo.
search-a-little-harder-for-mkimage.patch
------------------------------------------------------
Subject: search a little harder for mkimage
From: "Mike Frysinger" <[email protected]>
> Check to see if `${CROSS_COMPILE}mkimage` exists and if not, fall back to
> the standard `mkimage`
Why this can't be done by
PATH=$CROSS_COMPILE:$PATH
in your environment?
> The Blackfin toolchain includes mkimage, but we dont want to namespace
> collide with any of the user's system setup, so we prefix it with our
> toolchain name.
If that matter, `type -path' is bashizm (BloAted SHell), and "blackbox"
with "dash" (very good `sh' equivalents) will fail. I would recomend to
use "which" command (btw, Debian has `sh' version of it), if you
concerned about size and performance.
Nack + proposition to move from `bash' to `sh'.
-MKIMAGE=$(type -path mkimage)
+MKIMAGE=$(type -path ${CROSS_COMPILE}mkimage)
if [ -z "${MKIMAGE}" ]; then
- # Doesn't exist
- echo '"mkimage" command not found - U-Boot images will not be built' >&2
- exit 0;
+ MKIMAGE=$(type -path mkimage)
+ if [ -z "${MKIMAGE}" ]; then
+ # Doesn't exist
+ echo '"mkimage" command not found - U-Boot images will not be built' >&2
+ exit 0;
+ fi
fi
____
On Thu, 8 Feb 2007 06:24:40 +0100 Oleg Verych <[email protected]> wrote:
> If that matter, `type -path' is bashizm (BloAted SHell), and "blackbox"
> with "dash" (very good `sh' equivalents) will fail.
Does the kernel presently build with that shell?
> make-mkcompile_h-use-lang=c-and-lc_all=c-for-cc-v.patch
[]
> Fix a minor bug in mkcompile_h. As one can see, the current locale is used
> while getting the version of gcc. This produces problems when a locale
> other than C or en_US is used. As an example, my /proc/version contains
> Turkish characters in iso-8859-9 encoding.
>
> This patch fixes this issue by making sure that the C locale is used to get
> gcc's version.
Files in C must be in ASCII. Thus, my proposition is to
"export LC_ALL=C LANG=C" first, and remove any all other "LC_ALL=C
LANG=C", to have "compile.h" in it.
@@ -58,7 +58,7 @@ UTS_TRUNCATE="sed -e s/\(.\{1,$UTS_LEN\}
echo \#define LINUX_COMPILE_DOMAIN
fi
- echo \#define LINUX_COMPILER \"`$CC -v 2>&1 | tail -n 1`\"
+ echo \#define LINUX_COMPILER \"`LC_ALL=C LANG=C $CC -v 2>&1 | tail -n 1`\"
) > .tmpcompile
# Only replace the real compile.h if the new one is different,
_
Patches currently in -mm which might be from [email protected] are
make-mkcompile_h-use-lang=c-and-lc_all=c-for-cc-v.patch
On Wed, Feb 07, 2007 at 09:19:21PM -0800, Andrew Morton wrote:
> On Thu, 8 Feb 2007 06:24:40 +0100 Oleg Verych <[email protected]> wrote:
>
> > If that matter, `type -path' is bashizm (BloAted SHell), and "blackbox"
> > with "dash" (very good `sh' equivalents) will fail.
>
> Does the kernel presently build with that shell?
build - yes, with dash being `$(shell)'. All scripts with `#!/bin/bash'
of course use bash, example is gen_initramfs_list.sh.
Trivial shell scripts, especially for embedded archs (Blackfin is
one, IIRC), may be easily converted.
BTW, Debian shell policy is to be bashizms-clear. Purpose -- to have
compatibility with any `sh'. Shall we?
____
On 2/8/07, Oleg Verych <[email protected]> wrote:
> > Check to see if `${CROSS_COMPILE}mkimage` exists and if not, fall back to
> > the standard `mkimage`
>
> Why this can't be done by
>
> PATH=$CROSS_COMPILE:$PATH
>
> in your environment?
because it wouldnt matter ? the tool is called
"$CROSS_COMPILE-mkimage", it isnt $CROSS_COMPILE_PATH/mkimage
> > The Blackfin toolchain includes mkimage, but we dont want to namespace
> > collide with any of the user's system setup, so we prefix it with our
> > toolchain name.
>
> If that matter, `type -path' is bashizm (BloAted SHell), and "blackbox"
> with "dash" (very good `sh' equivalents) will fail. I would recomend to
> use "which" command (btw, Debian has `sh' version of it), if you
> concerned about size and performance.
>
> Nack + proposition to move from `bash' to `sh'.
the script already uses "#!/bin/bash" and the patch doesnt change any
of the existing conventions ... so if you want to rewrite the existing
code to be POSIX compliant, then do so so i can add back in support
for $CROSS_COMPILE-mkimage
-mike
On 2/8/07, Oleg Verych <[email protected]> wrote:
> On Wed, Feb 07, 2007 at 09:19:21PM -0800, Andrew Morton wrote:
> > On Thu, 8 Feb 2007 06:24:40 +0100 Oleg Verych <[email protected]> wrote:
> >
> > > If that matter, `type -path' is bashizm (BloAted SHell), and "blackbox"
> > > with "dash" (very good `sh' equivalents) will fail.
> >
> > Does the kernel presently build with that shell?
>
> build - yes, with dash being `$(shell)'. All scripts with `#!/bin/bash'
> of course use bash, example is gen_initramfs_list.sh.
which is what mkuboot.sh is using now
> Trivial shell scripts, especially for embedded archs (Blackfin is
> one, IIRC), may be easily converted.
yes, but Blackfin is no-mmu so converting the script to use POSIX
shell is pointless to us since no-mmu is not a self-hosting
environment
-mike
On Thu, Feb 08, 2007 at 12:58:26AM -0500, Mike Frysinger wrote:
> On 2/8/07, Oleg Verych <[email protected]> wrote:
> >On Wed, Feb 07, 2007 at 09:19:21PM -0800, Andrew Morton wrote:
> >> On Thu, 8 Feb 2007 06:24:40 +0100 Oleg Verych <[email protected]>
> >wrote:
> >>
> >> > If that matter, `type -path' is bashizm (BloAted SHell), and "blackbox"
> >> > with "dash" (very good `sh' equivalents) will fail.
> >>
> >> Does the kernel presently build with that shell?
> >
> >build - yes, with dash being `$(shell)'. All scripts with `#!/bin/bash'
> >of course use bash, example is gen_initramfs_list.sh.
>
> which is what mkuboot.sh is using now
>
> >Trivial shell scripts, especially for embedded archs (Blackfin is
> >one, IIRC), may be easily converted.
>
> yes, but Blackfin is no-mmu so converting the script to use POSIX
> shell is pointless to us since no-mmu is not a self-hosting
> environment
Heh, did i say POSIX? I said bloated shell, from man bash:
BUGS
It's too big and too slow.
____
On 2/8/07, Oleg Verych <[email protected]> wrote:
> On Thu, Feb 08, 2007 at 12:58:26AM -0500, Mike Frysinger wrote:
> > On 2/8/07, Oleg Verych <[email protected]> wrote:
> > >Trivial shell scripts, especially for embedded archs (Blackfin is
> > >one, IIRC), may be easily converted.
> >
> > yes, but Blackfin is no-mmu so converting the script to use POSIX
> > shell is pointless to us since no-mmu is not a self-hosting
> > environment
>
> Heh, did i say POSIX?
/bin/sh is the POSIX shell ... if you want to switch off of /bin/bash,
then the only other sane option is /bin/sh which means rewriting the
code to be POSIX compliant
> I said bloated shell, from man bash:
>
> BUGS
> It's too big and too slow.
we get it, you dont like bash, why do you feel the need to keep making
these statements ?
-mike
On Thu, Feb 08, 2007 at 12:56:17AM -0500, Mike Frysinger wrote:
> On 2/8/07, Oleg Verych <[email protected]> wrote:
> >> Check to see if `${CROSS_COMPILE}mkimage` exists and if not, fall back to
> >> the standard `mkimage`
> >
> >Why this can't be done by
> >
> > PATH=$CROSS_COMPILE:$PATH
> >
> >in your environment?
>
> because it wouldnt matter ? the tool is called
> "$CROSS_COMPILE-mkimage", it isnt $CROSS_COMPILE_PATH/mkimage
Well, i mean search for your `mkimage'.
Let's see how all this used in Makefiles (avr32, ppc, sh are same)
../arch/arm/boot/Makefile:
MKIMAGE := $(srctree)/scripts/mkuboot.sh
...
quiet_cmd_uimage = UIMAGE $@
cmd_uimage = $(CONFIG_SHELL) $(MKIMAGE) -A arm -O linux -T kernel \
-C none -a $(ZRELADDR) -e $(ZRELADDR) \
-n 'Linux-$(KERNELRELEASE)' -d $< $@
type, which with bash or whatever, doesn't matter. All they need *your*
toolchain in $PATH, why not just to put "$CROSS_COMPILE-mkimage" instead
of $(CONFIG_SHELL) $(MKIMAGE) here? mkuboot.sh just searches $PATH for
mkimage and run it. Double overkill, no?
> >> The Blackfin toolchain includes mkimage, but we dont want to namespace
> >> collide with any of the user's system setup, so we prefix it with our
> >> toolchain name.
> >
> >If that matter, `type -path' is bashizm (BloAted SHell), and "blackbox"
> >with "dash" (very good `sh' equivalents) will fail. I would recomend to
> >use "which" command (btw, Debian has `sh' version of it), if you
> >concerned about size and performance.
> >
> >Nack + proposition to move from `bash' to `sh'.
>
> the script already uses "#!/bin/bash" and the patch doesnt change any
> of the existing conventions ... so if you want to rewrite the existing
> code to be POSIX compliant, then do so so i can add back in support
> for $CROSS_COMPILE-mkimage
To run faster, but let me stop here.
____
On 2/8/07, Oleg Verych <[email protected]> wrote:
> On Thu, Feb 08, 2007 at 12:56:17AM -0500, Mike Frysinger wrote:
> > On 2/8/07, Oleg Verych <[email protected]> wrote:
> > >> Check to see if `${CROSS_COMPILE}mkimage` exists and if not, fall back to
> > >> the standard `mkimage`
> > >
> > >Why this can't be done by
> > >
> > > PATH=$CROSS_COMPILE:$PATH
> > >
> > >in your environment?
> >
> > because it wouldnt matter ? the tool is called
> > "$CROSS_COMPILE-mkimage", it isnt $CROSS_COMPILE_PATH/mkimage
>
> Well, i mean search for your `mkimage'.
>
> Let's see how all this used in Makefiles (avr32, ppc, sh are same)
>
> ../arch/arm/boot/Makefile:
>
> MKIMAGE := $(srctree)/scripts/mkuboot.sh
> ...
> quiet_cmd_uimage = UIMAGE $@
> cmd_uimage = $(CONFIG_SHELL) $(MKIMAGE) -A arm -O linux -T kernel \
> -C none -a $(ZRELADDR) -e $(ZRELADDR) \
> -n 'Linux-$(KERNELRELEASE)' -d $< $@
>
> type, which with bash or whatever, doesn't matter. All they need *your*
> toolchain in $PATH, why not just to put "$CROSS_COMPILE-mkimage" instead
> of $(CONFIG_SHELL) $(MKIMAGE) here? mkuboot.sh just searches $PATH for
> mkimage and run it. Double overkill, no?
by this argument, why does mkuboot.sh exist at all then ? let's
simply delete mkuboot.sh and change all arch Makefile's like so:
- $(CONFIG_SHELL) $(MKIMAGE) ...
+ -mkimage ...
i of course prefer the existing solution: call the mkuboot.sh script
which checks for a few variations of the `mkimage` binary and if it
does not exist, output a friendly message
-mike
On Thu, Feb 08, 2007 at 02:40:28AM -0500, Mike Frysinger wrote:
[]
> by this argument, why does mkuboot.sh exist at all then ? let's
> simply delete mkuboot.sh and change all arch Makefile's like so:
> - $(CONFIG_SHELL) $(MKIMAGE) ...
> + -mkimage ...
Yes (with TOOLCHAIN prefix).
> i of course prefer the existing solution: call the mkuboot.sh script
> which checks for a few variations of the `mkimage` binary and if it
> does not exist, output a friendly message
so as `make' will, but better than patched "friendly message", which
doesn't reflect: neither change to toolchain prefix, nor possible
permission problems, or what ever it can be, preventing actual running
the command ;)
____
On Feb 8 2007 07:43, Oleg Verych wrote:
>> >>
>> >> > If that matter, `type -path' is bashizm (BloAted SHell), and "blackbox"
>> >> > with "dash" (very good `sh' equivalents) will fail.
>> >>
>> >> Does the kernel presently build with that shell?
>> >
>> >build - yes, with dash being `$(shell)'. All scripts with `#!/bin/bash'
>> >of course use bash, example is gen_initramfs_list.sh.
>>
>
>Heh, did i say POSIX? I said bloated shell, from man bash:
>
>BUGS
> It's too big and too slow.
Like it or lump it. Improve it, or write your own bash-compliant sh. :)
On Wed, Feb 07, 2007 at 03:52:54PM -0800, Linus Torvalds wrote:
>
>
> On Thu, 8 Feb 2007, Roman Zippel wrote:
> >
> > Sorry, it needs more changes, the patch simply wasn't ready.
>
> One problem I find very problematic with all the Kbuild setup is that
> people tend to be very quiet about any build issues until they simply go
> in.
>
> Things don't "get ready" on their own. In other areas, people comment on
> why they don't like patches. In Kbuild, for some reason, we often seem to
> have this situation where people don't react at all.
>
> Sam is great about maintaining the kernel build stuff most of the time,
> but because it's clearly a "secondary" thing, there tends to be some
> periods when nothing happens. Which is problematic for me..
Sorry about my silence for now three months.
Been overly busy and with family now extended to three kids takes time too.
I will be back in a months time - maybe a bit sooner.
As for the Kbuild area I usual have patches cooking in -mm for a while
before pushing to you - comments are usual few when I post patches
which I take as a sign that most people do not care about Kbuild
as long as it works, other are not into the makefile trickery,
and also that the patches are small logical steps (which is
true for all contributions and not just mine).
Sam
Hi,
On Wed, 7 Feb 2007, Andrew Morton wrote:
> I'm sitting on these:
>
> search-a-little-harder-for-mkimage.patch
> make-mkcompile_h-use-lang=c-and-lc_all=c-for-cc-v.patch
> add-mailmap-for-proper-git-shortlog-output.patch
> qconf-immediately-update-integer-and-string-values-in-xconfig-display-take-2.patch
> qconf-relocate-search-command.patch
> qconf-fix-showing-help-info-on-failed-search.patch
> qconf-back-button-behaviour-normalization.patch
> kbuild-remove-references-to-deprecated-prepare-all-target.patch
> new-toplevel-target-headers_check_all.patch
>
> But I'm not sure that anyone has reviewed them much.
Patches look fine and most of the kconfig related patches are already the
result of a review.
bye, Roman
Hi,
On Thu, 8 Feb 2007, Oleg Verych wrote:
> BTW, Debian shell policy is to be bashizms-clear. Purpose -- to have
> compatibility with any `sh'. Shall we?
Wrong.
http://www.debian.org/doc/debian-policy/ch-files.html#s-scripts
bye, Roman
On Thu, Feb 08, 2007 at 05:38:28PM +0100, Roman Zippel wrote:
> Hi,
>
> On Thu, 8 Feb 2007, Oleg Verych wrote:
>
> > BTW, Debian shell policy is to be bashizms-clear. Purpose -- to have
> > compatibility with any `sh'. Shall we?
>
> Wrong.
>
> http://www.debian.org/doc/debian-policy/ch-files.html#s-scripts
"""
You may wish to restrict your script to POSIX features when possible
so that it may use /bin/sh as its interpreter. If your script works
with dash (originally called ash), it's probably POSIX compliant, but
if you are in doubt, use /bin/bash.
"""
I think, it's OK to start with ;)
> bye, Roman
____