On Saturday 05 September 2009 06:42:29 Bernhard Reutner-Fischer wrote: > On Fri, Sep 04, 2009 at 03:07:23PM -0500, Rob Landley wrote: > >Before the August 25 commit "default ?conf to native arch", I could do > > this: > > > >make KCONFIG_ALLCONFIG=miniconfig-uClibc.$ARCH allnoconfig && > >make KERNEL_HEADERS="${STAGE_DIR}/include" PREFIX="${STAGE_DIR}/" \ > > CROSS="${ARCH}-" RUNTIME_PREFIX=/ DEVEL_PREFIX=/ -j $CPUS \ > > install hostutils > > ARCH= > We _could_ default to the configured arch, if > - a .config exists and > ifeq ($(origin ARCH),command line) or undefined > if people prefer that logic. My setup now always passes the ARCH but as > you prefer.
Sorry if I'm behind on this thread, I started my annual caffeine detox two days ago and have spent most of the time since then sleeping. (And of course _now_ they restock the orange mango passion fruit rockstar drinks. Grumble.) I never previously supplied ARCH= to the build because no uClibc before now ever needed it. I can start doing so (redundant as it seems in this context), but could you confirm that the ARCH names you need will consistently match the 2.6 kernel? Even when the kernel does things like the ppc->powerpc migration? How will you handle somebody building for ARCH=x86 (which works fine in the kernel, "ARCH=i386" is a synonym for ARCH=x86 with CONFIG_64BIT=y forced on). Also, are you planning on hiding the existing architecture selection menu now that you've changed how you prefer to configure this stuff? Oh, and documenting this somewhere might be nice. This is a big change from the entire history of uClibc, I'm not the only one it's going to hit. If you were going to make it so the .config file no longer contained any configuration-specific information, so I could use the same config file for several different target architectures, that change might actually be useful to me. (Although not really, because there would still be different floating point options and such on some architectures.) But requiring this information to be _redundantly_ specified has no obvious benefit, and duplicating an architectural limitation of the kernel's kconfig layout which uClibc never suffered from makes no sense. Rob -- Latency is more important than throughput. It's that simple. - Linus Torvalds _______________________________________________ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc