Re: Running Shell Commands

Brian

Thanks for looking into this, I finally settled on running

make distclean
make allmodconfig

make allmodconfig creates a .config file if it doesn't exist.

Anyways, it all works now.

On a related note I need to get a new version of those git patches to
you the interface to cg-update changed between .8 and .10.  

Best

-bp

> I played around a bit with this.. it seems that there are a couple of ways to
> mess up the argv array that result in 'make' trying to build something that's
> not going to work, which then causes .config to be corrupted. Once .config is
> mussed, those same commands fail with an error from Make, because they're
> including .config (which is no longer a valid Makefile).
> 
> In particular, if the top-level Makefile doesn't recognize the target you're
> building as one that creates a config file, it will attempt to 'include
> .config', which will fail if .config is corrupted. So my hunch is that you
> got a corrupted .config while you were getting to the correct argv value, and
> that builds still using the wrong argv value would cause the Make error you
> described. Something like ['make', 'allmodconfig > .config'] is one such
> troublesome argv value, as it attempts to build a target named 'allmodconfig
> > .config', which doesn't exist, while ['make', '-d', 'allmodconfig >
> .config'] (which I did while trying to figure out what target 'allmodconfig >
> .config' made it build) produced a corrupted .config file, even though the
> top-level shell was not being asked to redirect anything to .config. I
> suspect that somewhere the Makefile is spawning off a sub-Make, and passing
> its target to that invocation with a regular '/bin/sh -c', so the shell
> redirection is happening when that internal Make runs.
> 
> Try deleting .config altogether, then re-running the step. Actually, the way
> to do this is to write a shell script that starts with nothing, does the
> checkout, then does all the desired commands. Don't try to write the build
> steps until that script works without human intervention. One of the problems
> with complex persistent-configuration systems like the linux kernel is that
> it's hard to know what state is "sticky", and a human-edited tree may have
> something lying around that makes it all work, which the completely
> machine-generated one might not have.
> 
> let me know how that goes,
>  -Brian

signature.asc
Description: Digital signature