In [1] we document three approaches, dependending on the package's usual handling of imported/generated files.
Dima Pasechnik wrote: > If a project does not use git's submodules, noone wants an extra > complexity of submodules to be added to the build system just due to > the need for gnulib. Sure. No one forces you to use a git submodule. As written in [1]: "The alternative is to always follow the newest Gnulib automatically. Note that this can cause breakages at unexpected moments, namely when a broken commit is pushed in Gnulib. It does not happen often, but it does happen." > In some projects I am or was involved, it's basically the case that the code > injected by > the gnulib-tool got committed into the tree, and blissfully forgotten > about. Yes, that's one possibility. > Why you at gnulib headquarters want large chunks of gnulib > scattered accross many, many thousands of downstream git trees, I don't know. This is not what we "want". The documentation [1] gives three options. You choose the one that fits best for your package. > My point is that it's used "elsewhere" not in the way you envision, but > by simply committing the code produced by gnulib-tool into the source > tree, and forgetting all about it. You must have studied the various packages that use gnulib quite extensively, but I have done that too. My impression is that the vast majority follows the principle "don't commit generated files into version control", that is, they use approach 2, not approach 1, from [1]. Bruno [1] https://www.gnu.org/software/gnulib/manual/html_node/VCS-Issues.html