Re: non-interactive build question
Hi Bernhard,
On Wed, Nov 06, 2013 at 10:51:21PM +0100, Bernhard Reutner-Fischer wrote:
> On 16 October 2013 09:02, Mike Frysinger wrote:
> > alternatively, we could update our kconfig snapshot to the latest kernel
> > which would get use miniconfig support
>
> yea, i've done that now but syncing kconfig is always a PITA, still
> didn't change much over the years.
> Anyways.
Thanks.
> It would be awesome if somebody would try to push parts of
> extra/config/kconfig-to-uclibc.tar.gz
> upstream (mike? anyone? *blink* :)
Does http://ymorin.is-a-geek.org/git/kconfig-frontends/ help? (Added Yann to
Cc).
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: non-interactive build question
On 6 November 2013 22:51, Bernhard Reutner-Fischer wrote: > On 16 October 2013 09:02, Mike Frysinger wrote: >> On Monday 14 October 2013 12:43:34 Steve Ellcey wrote: >>> I am new to building uclibc, but have experience building glibc and newlib, >>> and I have a question about the best way to build multiple versions of >>> uclibc from a script without any user interaction. >> >> you have experience building the kernel though right ? uClibc largely >> behaves >> the same as that. >> >>> Currently, I run 'make defconfig' to create a default .config file and then >>> use grep to modify the .config file before each build (strip out some lines >>> and then append my versions back in). I.e. I remove the ARCH_BIG_ENDIAN=y >>> line and then add in a ARCH_LITTLE_ENDIAN=y line. to change from big-endian >>> to little-endian or I may pick a different MIPS ABI. But what I noticed is >>> that when I run the normal 'make' command after modifying .config is that >>> my .config changes are getting wiped out and .config is getting restored >>> to a default state. >> >> try `make oldconfig` first (assuming you pass ARCH=/etc... on the command >> line) >> >>> Can someone explain why this is happening and if there is a way to prevent >>> it? Is there a better way to do multiple uclibc builds with different >>> defaults and without requiring any user interaction? >> >> usually the simplest thing is to create the .config files by hand as you care >> about them, and then use those when building >> >> alternatively, we could update our kconfig snapshot to the latest kernel >> which >> would get use miniconfig support More to the point: Not sure if that helps, but my way of configuring non-interactively is "documented" here, fwiw: http://git.openembedded.org/openembedded-core/tree/meta/recipes-core/uclibc The configury that derives from the desired surrounding can be found in uclibc-config.inc (There's still a FIXME WRT mips abi in there due to lack of time, i fear) and the base configury lives in uclibc.inc This latter config mentions a "merge_config.sh" which may or may not be handy for your purposes. I take it that i do not need to point you to kconfig howtos, else see accompanying kconfig docs in uClibc/extra/config and/or grep for getenv. Please let us know if you encounter specific problems. thanks, ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: non-interactive build question
On 16 October 2013 09:02, Mike Frysinger wrote: > On Monday 14 October 2013 12:43:34 Steve Ellcey wrote: >> I am new to building uclibc, but have experience building glibc and newlib, >> and I have a question about the best way to build multiple versions of >> uclibc from a script without any user interaction. > > you have experience building the kernel though right ? uClibc largely behaves > the same as that. > >> Currently, I run 'make defconfig' to create a default .config file and then >> use grep to modify the .config file before each build (strip out some lines >> and then append my versions back in). I.e. I remove the ARCH_BIG_ENDIAN=y >> line and then add in a ARCH_LITTLE_ENDIAN=y line. to change from big-endian >> to little-endian or I may pick a different MIPS ABI. But what I noticed is >> that when I run the normal 'make' command after modifying .config is that >> my .config changes are getting wiped out and .config is getting restored >> to a default state. > > try `make oldconfig` first (assuming you pass ARCH=/etc... on the command > line) > >> Can someone explain why this is happening and if there is a way to prevent >> it? Is there a better way to do multiple uclibc builds with different >> defaults and without requiring any user interaction? > > usually the simplest thing is to create the .config files by hand as you care > about them, and then use those when building > > alternatively, we could update our kconfig snapshot to the latest kernel which > would get use miniconfig support yea, i've done that now but syncing kconfig is always a PITA, still didn't change much over the years. Anyways. It would be awesome if somebody would try to push parts of extra/config/kconfig-to-uclibc.tar.gz upstream (mike? anyone? *blink* :) Namely: 02: getopt b0rkenness, relies on getopt_long, hardcoded. The 02 uses non-long unconditionally but you get the idea of how that would look like if it was written convieniently.. You'd have to rephrase that obviously but please try to keep the short letters as i suggests, TIA. 03: O= I could start an endless rant about doing out-of-tree builds which i'll try to resist here and now. Put short, i really wonder how kernel's O= works, if at all. The 03 takes care that in uClibc a $ git clean -fxd && rm -rf /tmp/x /tmp/i $ sudo chown -R 0.0 . $ make O=/tmp/x ;# does defconfig or menuconfig, i forgot which one. $ make O=/tmp/x #$make O=/tmp/x PREFIX=/tmp/i works. Reminds me that i forgot to update Makefile.help (patches welcome..) So there's your savedefconfig. HTH, ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: non-interactive build question
On 10/14/2013 11:43:34 AM, Steve Ellcey wrote: I am new to building uclibc, And I'm about two weeks behind on my email. :) but have experience building glibc and newlib, and I have a question about the best way to build multiple versions of uclibc from a script without any user interaction. Currently, I run 'make defconfig' to create a default .config file and then use grep to modify the .config file before each build (strip out some lines and then append my versions back in). I.e. I remove the ARCH_BIG_ENDIAN=y line and then add in a ARCH_LITTLE_ENDIAN=y line. to change from big-endian to little-endian or I may pick a different MIPS ABI. But what I noticed is that when I run the normal 'make' command after modifying .config is that my .config changes are getting wiped out and .config is getting restored to a default state. Can someone explain why this is happening and if there is a way to prevent it? Is there a better way to do multiple uclibc builds with different defaults and without requiring any user interaction? In Aboriginal Linux I use the miniconfig technique, which starts with allnoconfig and switches on specific symbols, allowing dependency resolution to happen to each one. You basically make a file going CONFIG_BLAH=y CONFIG_THINGY=42 And so on for each symbol you'd modify by hand if you were doing a menuconfig after allnoconfig, and then you go: make allnoconfig KCONFIG_ALLCONFIG=mini.conf My basic uClibc config is here: http://landley.net/hg/aboriginal/file/1620/sources/baseconfig-uClibc That's the set of symbols common to all architures. The build adds the architecture specific symbols from the architecture config files in targets directory: http://landley.net/hg/aboriginal/file/1620/sources/targets So in the case of armv5l it adds: TARGET_arm=y CONFIG_ARM_EABI=y ARCH_WANTS_LITTLE_ENDIAN=y DOPIC=y For sparc it adds this instead: TARGET_sparc=y UCLIBC_HAS_FPU=y FORCE_SHAREABLE_TEXT_SEGMENTS=y I note that I patched my copy of uClibc to remove the pointless "ARCH_HAS_MMU" symbol: http://landley.net/hg/aboriginal/file/1620/sources/patches/uClibc-mmu.patch If you don't patch ARCH_HAS_MMU out, you'll have to add it to your config in order to be able to say ARCH_USE_MMU (which is the actual meaningful symbol). Rob ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: non-interactive build question
On 2013-10-16, Qais Yousef wrote:
>> This seems to work but I would still like to try and find a way to
>> generate the .config file I want without having to run menuconfig at
>> all. I think what I would really like is something like:
>
> You'll only have to run menuconfig manually once.
>
> Once you have a good set of config files it should be easy to
> manipulate them to produce other variants you like. I can't see how
> you can avoid the first manual menuconfig step personally.
Manipulating .config files programmatically is pretty easy.
The shell script I use to build a buildroot-based system doesn't
require any use of menuconfig.
The one thing you have to remember when manipulating a .config file is
that changing a config value often has side effects. For example: when
you want to enable and configure a previously disabled subsystem, you
have to do it in stages:
1) Enable the subsystem
2) Run "make oldconfig" to make the subsystem's configuration items
appear in the .config file with default values.
3) Enable/Disable/Set the subsystem's configuration items.
Depending on how the configuration items are defined, you can end up
with this process nesting several levels deep.
To that end, here are 3 bash functions I use:
set -o nounset
set -o errexit
# low level functions used to manipulate linux kernel-style .config
# files.
function SyncConfig()
{
yes '' | $Make oldconfig >/dev/null
}
# By default, UnsetValue and SetValue will, after modifying the
# .config file, do a "make oldconfig" to re-normalize the .config
# file. Use the -n option to prevent that.
function UnsetValue()
{
dosync=y
test "$1" = '-n' && { dosync=n; shift; }
Variable="$1"
echo "UnsetValue $Variable"
sed -i "s/^${Variable}=.*/# ${Variable} is not set/g" .config
test $dosync = y && SyncConfig
return 0
}
function SetValue()
{
dosync=y
test "$1" = '-n' && { dosync=n; shift; }
Variable="$1"
# default value is 'y'
Value="${2-y}"
echo "SetValue $Variable $Value"
# if value isn't 'y', then put it in double quotes
test "$Value" != y && Value="\"$Value\""
# escape any slashes
Value=${Value//\//\\\/}
sed -i "s/^${Variable}=.*/${Variable}=${Value}/g" .config
sed -i "s/^# ${Variable} is not set.*/${Variable}=${Value}/g" .config
test $dosync = y && SyncConfig
return 0
}
Then you can make function calls like this in a build script:
TPath=/path/to/my/toolchain
SetValue BR2_TOOLCHAIN_EXTERNAL_PATH "$TPath"
--
Grant Edwards grant.b.edwardsYow! Now that I have my
at "APPLE", I comprehend COST
gmail.comACCOUNTING!!
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
RE: non-interactive build question
> This seems to work but I would still like to try and find a way to generate > the > .config file I want without having to run menuconfig at all. I think what I > would > really like is something like: You'll only have to run menuconfig manually once. Once you have a good set of config files it should be easy to manipulate them to produce other variants you like. I can't see how you can avoid the first manual menuconfig step personally. Qais ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: non-interactive build question
On Monday 14 October 2013 12:43:34 Steve Ellcey wrote: > I am new to building uclibc, but have experience building glibc and newlib, > and I have a question about the best way to build multiple versions of > uclibc from a script without any user interaction. you have experience building the kernel though right ? uClibc largely behaves the same as that. > Currently, I run 'make defconfig' to create a default .config file and then > use grep to modify the .config file before each build (strip out some lines > and then append my versions back in). I.e. I remove the ARCH_BIG_ENDIAN=y > line and then add in a ARCH_LITTLE_ENDIAN=y line. to change from big-endian > to little-endian or I may pick a different MIPS ABI. But what I noticed is > that when I run the normal 'make' command after modifying .config is that > my .config changes are getting wiped out and .config is getting restored > to a default state. try `make oldconfig` first (assuming you pass ARCH=/etc... on the command line) > Can someone explain why this is happening and if there is a way to prevent > it? Is there a better way to do multiple uclibc builds with different > defaults and without requiring any user interaction? usually the simplest thing is to create the .config files by hand as you care about them, and then use those when building alternatively, we could update our kconfig snapshot to the latest kernel which would get use miniconfig support -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
RE: non-interactive build question
On Tue, 2013-10-15 at 03:31 -0700, Qais Yousef wrote: > Modifying the .config manually is generally bad. The best way to do it I'd > say is by > running menuconfig for each config you want then copy the generated .config > to a > different file. In your script then simply copy the saved config file to > replace > the .config before running make. You might want to run make oldconfig after > replacing > .config to ensure any new values your config files doesn't have would be > resolved to > default. > > HTH, > Qais This seems to work but I would still like to try and find a way to generate the .config file I want without having to run menuconfig at all. I think what I would really like is something like: make ARCH=mips CROSS_COMPILE=mips-linux-gnu- ENDIAN=little \ ISA=mips32 defconfig Where the ENDIAN value and the ISA value would, somehow, change the default settings in the generated .config file from big-endian to little-endian and from mips1 to mips32. But I am not sure that there is any way to pass in values like that from the make command into the values used by defconfig. Steve Ellcey sell...@mips.com ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: non-interactive build question
On Mon, 2013-10-14 at 22:21 +0200, Carmelo Amoroso wrote: > Hello > > Il 14 ottobre 2013 18:43:34 "Steve Ellcey " ha scritto: > > > > I am new to building uclibc, but have experience building glibc and newlib, > > and I have a question about the best way to build multiple versions of > > uclibc > > from a script without any user interaction. > > > > Currently, I run 'make defconfig' to create a default .config file and then > > This will assume the arch of the host ... I doubt it will work for MIPS. > Pass proper arch and cross prefix. I am passing ARCH and CROSS_COMPILE and getting a .config file for MIPS. > > use grep to modify the .config file before each build (strip out some lines > > and then append my versions back in). I.e. I remove the ARCH_BIG_ENDIAN=y > > line and then add in a ARCH_LITTLE_ENDIAN=y line. to change from big-endian > > to little-endian or I may pick a different MIPS ABI. But what I noticed is > > that when I run the normal 'make' command after modifying .config is that my > > .config changes are getting wiped out and .config is getting restored to a > > default state. > > > > Because your changes are not in sync with the build system. > Try applying them by menuconfig and than check your final .config. Running menuconfig is what I am trying to avoid. I want a non-interactive way to set the endian mode and other options to a value different then the default MIPS values but without requiring any user interaction. Steve Ellcey sell...@mips.com ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
RE: non-interactive build question
> I am new to building uclibc, but have experience building glibc and newlib, > and I > have a question about the best way to build multiple versions of uclibc from a > script without any user interaction. > > Currently, I run 'make defconfig' to create a default .config file and then > use grep > to modify the .config file before each build (strip out some lines and then > append > my versions back in). I.e. I remove the ARCH_BIG_ENDIAN=y line and then add > in a ARCH_LITTLE_ENDIAN=y line. to change from big-endian to little-endian or > I > may pick a different MIPS ABI. But what I noticed is that when I run the > normal > 'make' command after modifying .config is that my .config changes are getting > wiped out and .config is getting restored to a default state. > > Can someone explain why this is happening and if there is a way to prevent > it? Is > there a better way to do multiple uclibc builds with different defaults and > without > requiring any user interaction? Modifying the .config manually is generally bad. The best way to do it I'd say is by running menuconfig for each config you want then copy the generated .config to a different file. In your script then simply copy the saved config file to replace the .config before running make. You might want to run make oldconfig after replacing .config to ensure any new values your config files doesn't have would be resolved to default. HTH, Qais ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: non-interactive build question
Hello Il 14 ottobre 2013 18:43:34 "Steve Ellcey " ha scritto: I am new to building uclibc, but have experience building glibc and newlib, and I have a question about the best way to build multiple versions of uclibc from a script without any user interaction. Currently, I run 'make defconfig' to create a default .config file and then This will assume the arch of the host ... I doubt it will work for MIPS. Pass proper arch and cross prefix. use grep to modify the .config file before each build (strip out some lines and then append my versions back in). I.e. I remove the ARCH_BIG_ENDIAN=y line and then add in a ARCH_LITTLE_ENDIAN=y line. to change from big-endian to little-endian or I may pick a different MIPS ABI. But what I noticed is that when I run the normal 'make' command after modifying .config is that my .config changes are getting wiped out and .config is getting restored to a default state. Because your changes are not in sync with the build system. Try applying them by menuconfig and than check your final .config. Can someone explain why this is happening and if there is a way to prevent it? Is there a better way to do multiple uclibc builds with different defaults and without requiring any user interaction? Steve Ellcey sell...@mips.com Regards Carmelo ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc Inviato con AquaMail per Android http://www.aqua-mail.com ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
