One of the complaints that I continue to hear is that kbuild
is lacking a way to 'remember' the ARCH and CROSS_COMPILE
values originally used.
Likewise we have people that change ARCH settings and get
a lot of build errors due to asm symlink pointing at the
wrong directory.

This patch tries to address this by saving ARCH and
CROSS_COMPILE settings and error out if user specify
anohter ARCH or CROSS_COMPILE setting.
If there is inconsistency then error out and suggest
to run make mrproper.

This will as a side-effect prevent a build with the wrong
asm symlink.

The settings are stored in the build directory in a file
named "Kbuild.config" (should it be a .dot file?).

I have tested it here with success - but please give
it a try in your setup and let me know if anything breaks.

The patch is on top of latest linus tree but should apply
with some fuzz to -mm too (at least it apply on top of 
my kbuild.git tree).

PS. I do not like adding additional cruft to the top-level
Makefile but did not find an easy way to push this to
kconfig.

	Sam

diff --git a/Makefile b/Makefile
index 6fc97bf..9f6d03f 100644
--- a/Makefile
+++ b/Makefile
@@ -182,8 +182,33 @@ SUBARCH := $(shell uname -m | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ \
 # Default value for CROSS_COMPILE is not to prefix executables
 # Note: Some architectures assign CROSS_COMPILE in their arch/*/Makefile
 
-ARCH		?= $(SUBARCH)
-CROSS_COMPILE	?=
+# Kbuild save the ARCH and CROSS_COMPILE setting in Kbuild.config
+# Restore these settings and check that user did not specify
+# conflicting values.
+Kbuild.config: ;
+noconfigcheck-targets := clean mrproper distclean help %config
+
+ifneq ($(wildcard Kbuild.config),)
+        -include Kbuild.config
+        ifeq ($(filter $(noconfigcheck-targets),$(MAKECMDGOALS)),)
+                ifneq ($(CROSS_COMPILE),)
+                        ifneq ($(CROSS_COMPILE),$(KBUILD_CROSS_COMPILE))
+                                $(error CROSS_COMPILE changed from ...
[ message continues ]

Yea, finally.

What about, that this is the first ever prompt, that must be shown and
written to the .config?

The zeroth one is an config entry of kernel version(s), .config can
configure and thus build successfully.


This are among other ideas about kconfig/kbuild, you know nothing
about yet.

So, what do you think?

Also, i'd like to propose sequencing of config-enable-build-this-unit
in config file(s), thus Makefile(s) (sometimes very small and stupid)
will be not necessary. Additional link ordering can be supplied as
meta-config information there. Shell scripting, very ugly in the view
of make syntax, will be natural in config files. Extending build
process to get hidden dependencies or right linking/other magic is
part of particular configuration. Hm?

And i want to repeat this to the wall:

make is stupid `test -nt` (non POSIX, but accepted my shells and GNU test
feature). Making any kind of hashing to make dream of kbuild-2.5
developers/fans -- more complete `up-to-date' heuristic possible, is just
like `md5sum > $OBJDIR/heuristic.com`, which is config selectable (for
those, who don't like a bit of slowdown).
--
-o--=O`C
 #oo'L O
<___=E M
-

[ message continues ]

Two issues to fix before we can do this:
1) chocie values cannot have more than one prompt
2) We need to share much more Kconfig* between the individual architectures
   First step is to let all arch's use drivers/Kconfig

Let's get the two items above solved then we can revisit adding arch selection
to kconfig (where it belongs in the end).
Discussed before but so far no patches has shown up.

	Sam
-

[ message continues ]

2) isn't terribly difficult, just takes some time and willingness
of $arch maintainers to some changes, but please explain a bit more


---
~Randy
-

[ message continues ]

Maybe I didn't read carefully:  "to add arch selection to kconfig"..

arch/cris using drivers/Kconfig: patch is below (maintainer is

---

From: Randy Dunlap <randy.dunlap@oracle.com>

Move arch/cris to using drivers/Kconfig for its drivers config list.
When all arches do this, Sam can make more interesting improvements
to .config files.

Using drivers/Kconfig adds these kconfig files to cris:
connector, misc, ata, message/fusion (not avail.), macintosh (not avail.),
i2c, spi, w1, power, hwmon, mfd, video, hid, mmc, leds,
infiniband (not avail.), edac (not avail.), rtc, dma, auxdisplay,
kvm (not avail.), uio, and lguest (not avail.).

Many of these are already enabled/disabled per arch., so adding that
for cris can be done as required.

"not avail." means that this menu is not valid for this arch.
and won't be presented to users when running 'make *config'.

Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
 arch/cris/Kconfig |   40 +---------------------------------------
 1 file changed, 1 insertion(+), 39 deletions(-)

--- linux-2.6.23-rc9-git6.orig/arch/cris/Kconfig
+++ linux-2.6.23-rc9-git6/arch/cris/Kconfig
@@ -153,49 +153,11 @@ source arch/cris/arch-v10/drivers/Kconfi
 
 endmenu
 
-source "drivers/base/Kconfig"
-
 # standard linux drivers
-source "drivers/mtd/Kconfig"
-
-source "drivers/parport/Kconfig"
-
-source "drivers/pnp/Kconfig"
-
-source "drivers/block/Kconfig"
-
-source "drivers/md/Kconfig"
-
-source "drivers/ide/Kconfig"
-
-source "drivers/scsi/Kconfig"
-
-source "drivers/ieee1394/Kconfig"
-
-source "drivers/message/i2o/Kconfig"
-
-source "drivers/net/Kconfig"
-
-source "drivers/isdn/Kconfig"
-
-source "drivers/telephony/Kconfig"
-
-#
-# input before char - char/joystick depends on it. As does USB.
-#
-source "drivers/input/Kconfig"
-
-source "drivers/char/Kconfig"
-
-#source drivers/misc/Config.in
-source "drivers/media/Kconfig"
+source "drivers/Kconfig"
 
 source "fs/Kconfig"
 
-source ...
[ message continues ]

A prerequisite for moving ARCH selection to Kconfig is that we
read in all Kconfig files for all architectures.
To do so efficient we should avoind including the same Kconfig
file for each architecture which is obviously the case today.

The efficiency comes both with respect to reading the files but
also memory consumption. If we read in drivers/Kconfig only once
then we will avoid some duplication compared to reading drivers/Kconfig
once for each architecture.

The structure we should aim for is something like a top-level
Kconfig file that pull in relevant parts from the kernel tree
and where the arch Kconfig only pull in additional Kconfig files
from that arch.

When we get this far we will have a more logical structure
in the Kconfig file and their distribution.

But the showstopper is the part with choice value that cannot have more
than a single prompt so when we have the same choice value
used in two arch Kconfig files then kconfig will warn and the
choice will do the wrong thing.
I never took a deeper look at this - I seem to get distracted each
time I try to understand all the inner details of the kconfig
use of data structures.

	Sam

-

[ message continues ]

what occupying all my time now is to try to make fast and easy (text/tty)
user interface, based solely on TERM=linux capability. It is such, but
deep in ncurses/lxdialog wrappers. Having more flexible TUI without
all past stereotypes is the major point in making any progress for
flexible configuration interface. Remember, how blind `select` hurts.

All syntax wars are over, now order is the second thing to achieve. Like
in x86 merge case, this is purely technical thing with a bit of manual
work after that. sed magic for (nearly any kind :) of textual processing
i can guarantee without (yet another) C (like fixdep.c, parts of

Since i try to do test driven development, it's more easy for me to
understand/fix/test today's things via making bits from scratch. Fresh
view can do more on debugging of the logic level also.
____
-

[ message continues ]

A .dot file sounds better.

And even if not, generated files should IMHO not share the Kbuild* 
namespace with non-generated files.


cu
Adrian

BTW: I'm currently trying without success to understand why the
     drivers/infiniband/{hw/amso1100,ulp/srp}/Kbuild files are not
     named "Makefile".

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

-

[ message continues ]

or the inverse ;-)  Why all Makefiles (but the top level one ) are not
named Kbuild, considering that they are not valid (standalone) Makefile.

ciao
	cate
-

[ message continues ]

I will make it ".kbuild".
Droppeing the .config bits of the name will hopefully avoid that
Giacomo explained this already..
But I have never done a global renaming - the
pain/benefit ratio seems too low.

	Sam
-

[ message continues ]

Either keep all as "Makefile" or rename all.


cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

-

[ message continues ]

Can you do this in a way that there are still these ARCH/CROSS_COMPILE
lines that are just overriden when empty or have their default value? 

This way defaults could be still patched in for special cases.

-Andi
-

[ message continues ]

If it is OK to drop the $(SUBARCH) assingment like this then yes.
ARCH		?=
CROSS_COMPILE	?=

I was wondering why we had the empty CROSS_COMPILE assigment and this
explains why.
But why patch something in here in the fisrt place?
It seems to be a workaround for the actual issue this patch addresses - no?

	Sam
-

[ message continues ]

As long as both UML and normal architectures work still out of the 

Mostly.

The difference is that Kbuild.config would likely contain other stuff
too that might be not fit into a patch? Ok it's not a big difference.

-Andi

-

[ message continues ]

Does the UML build still work when you do that?

				Jeff

-- 
Work email - jdike at linux dot intel dot com
-

[ message continues ]

The original behaviour is kept is ARCH is not set on the
commandline and saved in .kbuild (Kbuild.config in the patch).

The logic goes basically like this:
If there is no .kbuild file then set ARCH = $(SUBARCH)
else set ARCH = saved ARCH from .kbuild.

And then a bit sanity check that the user does not
try to change architecture in the middle.

I actually used um as testing ground for this patch so
it works for um in my way of building um.

I considered switching architectures automagically
but concluded that in most cases when a user change ARCH
then that's because the user forgot to specify ARCH or more
seldom forgot what ARCH was being built in that directory.

	Sam
-

[ message continues ]

Great, thanks.

		Jeff

-- 
Work email - jdike at linux dot intel dot com
-

[ message continues ]

On Mon, 8 Oct 2007 22:02:55 +0200
-

[ message continues ]