Hi Colin, > These are intended to be variables that > a project can set in bootstrap.conf (the same way that projects in > languages that have package managers often pin particular versions of > their dependencies that they've tested), not command-line options or > environment variables.
Ah, I saw code that tests $GNULIB_REVISION without prior explicit initialization, so I assumed it would have to be set as an environment variable. But you're right, it can equally be set in bootstrap.conf - whichever is more convenient to the project or user. > I intended this to be nothing more than a way to > control the things that you can already control by way of .gitmodules, > except without having to use git submodules with all their little > oddities. Yes, this is good. What I'm saying is that code changes that offer more choice to the user should be accompanied with documentation changes, so that the user is aware of the choices that you offer them. Guessing what are the possible choices, by reading the code, is - as we just witnessed :-) - a bit hard. > The question "Which variables may I set in bootstrap.conf?" already has > much more than a single-sentence answer ... Yes, but now would be the good moment to start documenting it. At least for the part that affects how gnulib is being fetched/pulled/used. Bruno