Simon Josefsson wrote: > Thinking about all this, do we really need two new scripts? There > is inflation in all these tools and documentation files. Could the > separation be done via './bootstrap --pull' and './bootstrap --generate' > with the default './bootstrap' be to do both?
It's two different scripts because the developer runs them at different time points: * When starting to work on a package, after a period of inactivity, the developer will run $ git pull && ./autopull.sh Or when switching to a different branch: $ git checkout branch-x-y && ./autopull.sh * After making changes to the source code (including the source code of the submodules), the developer will run $ ./autogen.sh * After making changes to the source code (excluding the submodules and the bootstrap.conf), the developer will run $ ./autogen.sh --skip-gnulib Those packages that support this option document it like this: --skip-gnulib Avoid fetching files from Gnulib. This option is useful - when you are working from a released tarball (possibly with modifications), or - as a speedup, if the set of gnulib modules did not change since the last time you ran this script. For tools that are convenient to developers, long options are a handicap. (Do you like typing '../libtool --mode=execute gdb program' ?) The second reason for having two scripts is that the developer can change the source code of the submodules in between. Take, as an analogy, our usual build recipe: ./configure && make && make check Is every package shipping a 'build' script #!/bin/sh ./configure "$@" && ${MAKE-make} && ${MAKE-make} check ? No. Do we have a 'build' script that can be called as ./build --skip-configure ./build --skip-install ./build --only-make ? No again. Why? Because - The developers like to do some things between the various phases (e.g. remove -O2 options in the selected generated Makefiles). - There are many different ways a developer can work; for example, one developer may want every output to be stored in a log file; another developer wants to compare the output to the output of the previous run; and so on. It's easier for the developers to use the individual bricks (configure, make, etc.) rather than a script that does all at once. (I'm *not* talking about Visual Studio or Xcode addicts.) These considerations also apply to autopull.sh and autogen.sh. Bruno