Well the grep I sent was not ok. I think this one might be better: grep "^CONFIG" .config > .myconfig
Oliver According to Thorsten Fischer on Fri, Apr 30, 2010 at 09:50:55AM +0200: > Excerpts from Philip Prindeville's message of Fri Apr 30 02:27:21 +0200 2010: > > I'm working on a way to build various images from a single directory, > > and do it in an automated way. > > We do something similar; two different armeb images and a mipsel image > for every 'release'. We keep our code in a git repository. I have > written a build script that allows me to selectively build any or all of > the images, select which branch or commit ID to build from, add additional > packages, keep logs of builds with 'V=99' output, and so on. > > > What this means is, I need reliable ways to: > > * select certain menuconfig options from the CLI, rather than from the GUI; > > * reset the directory to a pristine state, i.e. that which it is > > immediately after an "svn co" with no stale files left around; > > > > How do I do this? > > For the selection on the CLI, create a .config with only the entries > that you require. Then run 'make defconfig'. That will create a valid > .config based on your selections. At the very least you will probably > want 'CONFIG_TARGET_<arch>_<profile_name>=y' to select the correct > profile. > > Note that for packages, you may need to explicitly add the dependencies, > too. I found that sometimes the dependency entries in a package's > Makefile are not honoured as I would have expected. > > > * reset the directory to a pristine state, i.e. that which it is > > immediately after an "svn co" with no stale files left around; > > I 'git clone' for every single image. It's quick compared to the time > spent on building and disk space is cheap. Also you retain state in case > of errors, which I found to be useful. > > > Also, what are the steps for using external feeds? I saw the help that > > "scripts/feeds" gives, but wanted more detailed info than that. > > For instance, how to cleanup or back out an external feed that I decide > > I don't want, or again putting things back into the "pristine" state above. > > Can't help you there, I never used those. We add external packages > directly to our tree. The main reason for that is reproducability: we > want a particular commit ID (plus its .config file, which is also saved) > to enable us to reproduce an image. > > Generally I found that wrapping builds in a simple script is a very > useful thing to have. > > > Cheers, > > t > -- > Thorsten Fischer, BOWL Project Administrator > <thors...@net.t-labs.tu-berlin.de> > Technische Universität Berlin, FG INET, 18th floor > Ernst-Reuter-Platz 7, 10587 Berlin, Germany > Tel: +49 30 835358542, Fax: +49 391 53478347 > _______________________________________________ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
