[PATCH build] Separate build and repository functions.

[Trevor Woerner]

On Fri, Sep 17, 2010 at 3:13 PM, Gaetan Nadon <memsize at videotron.ca> wrote:
> I like the idea, but not how it is implemented. Guess what, we use to have 2
> scripts, one to do clone/pull and build.sh without git operations. Do you
> know why the git functionality has been merged into build.sh? Because each
> script contained it's own list of modules which is a pain to maintain.
>
> You intuitively bridged the gap by writing the module set to a build.modules
> file to feed build.sh. That's one step forward compared to what we had. The
> downer is that the user would now have 3 files to worry about and how they
> relate to each other. Each script having its own set of options to memorize.
> You need to write instructions and so on.

(Just commenting on this one idea)

I think you may have misunderstood: I don't write "the module set to a
build.modules file to feed build.sh", I use the new "-L" option to
build.sh to have it generate the list for me on-the-fly. So I'm not
maintaining 3 files, just the two.

If you invoke "build.sh -L" all by itself (i.e. no $PREFIX required)
you get a list of the modules to build, in the correct order in which
they need to be built.

The build command in my example specifies a 3rd file, but that's just
the "autoresume" feature, which is a file that's been there all along,
there's no change to that part. The autoresume isn't necessary, you
could build without that option and the build would start with the
first module every time. "--autoresume" is not an option I've added,
it existed from when I started looking at the code. The "--autoresume"
option is something that was added by someone else before me to
replace the "-r" and "-f" options and combines them into one.

Brought to its logical conclusion, the only real reason for build.sh
would be to generate the list of modules in the right order,
everything else can be done with my proposed xcmd.sh script.

Sorry for the confusion.