On Mon, May 8, 2017 at 9:43 PM, Bruno Haible <br...@clisp.org> wrote: > Ævar Arnfjörð Bjarmason wrote: >> > When you use the --lgpl option to gnulib-tool, it should replace the >> > copyright headers of the files accordingly. If not, that's a bug in >> > gnulib-tool. >> >> That wasn't happening in the latest gnulib.git today: >> >> ---cut--- >> $ rm -rf /tmp/rx.tmp; ./gnulib-tool --version; ./gnulib-tool --lgpl >> --create-testdir --dir=/tmp/rx.tmp regex >/dev/null > > Well; I should have said "When you use the --lgpl option to gnulib-tool, > together with the --import / --add-import / --remove-import / --update > options". --create-testdir does not do this processing, because it's not > useful for a testdir. > >> As an aside, is there a way to make gnulib-tool emit just the *.c & >> *.h files needed for e.g. the regex module in some target directory? > > Well, you can "rm -rf glm4" after having run gnulib-tool. But this mode > of using gnulib-tool is not supported, because there is *plenty* of > autoconf macro processing that prepares the subsequent build. > >> I'm using gnulib-distributed files in a project that doesn't use the >> autoconf/automake/m4 macros > > In this situation I would suggest to create a subdirectory of the > project, with a configure.ac file of its own, just for building the > libgnu.a. This way, the configuration of the project stays the same > way as it is, i.e. the way the developers know it and like it, and > the subdirectory's Makefile.am and configure.ac deal only with gnulib. > >> But if the license header in the files themselves can't be trusted > > The license header in the files can be trusted _after_ you have used --lgpl > in combination with --import / --add-import / --remove-import / --update. > >> Aside from me not finding some invocation to the tool that surely >> exists to do this, is there a reason the file in git wouldn't just >> have the most permissive license it's licensed under in the header >> itself? > > The way we do the license handling in gnulib is the result of lengthy > discussions and lots of considerations. Of course your suggestion was > one of the approaches that were discussed, but it was not the one that > was adopted.
All makes sense. Thanks a lot for your help.
