Hello Collin, Collin Funk wrote: > Hello, here is a patch implementing the --gnu-make option for > gnulib-tool.py.
Thanks! Applied. This was already a major piece of work. > All of these > commits were grouped together and were similar so I felt like it > didn't make too much sense to handle them separately. Yes, keeping them together was the right thing to do. > I ended up testing these changes with Paul Eggert's merge-gnulib > script used by Emacs [1]. Maybe there is a better way to test it but > this seemed to work pretty well. First I would update the sources with > the regular gnulib-tool, save the generated Makefile, and then run the > script again with gnulib-tool.py. Perfect. That's the perfect way to test it this --gnu-make option. Just three small nits that you might want to revisit: * gnulib-tool.py line 610: + if modules != None and "tests" in mode and gnu_make: ^^^^^^^^^^^^^^^^^^^ What is the rationale for this condition? It is not present in the original. Can it be removed? * pygnulib/GLEmiter.py lines 732, 739: + allsnippets += re.sub(r'^if (.*)', r'ifneq (,$(\1))', amsnippet1) + allsnippets += re.sub(r'^if (.*)', r'ifneq (,$(\1))', amsnippet2) The regular expression is duplicated. The problem with duplicated code is that it very often leads to bugs in the future: Future code maintainers will see one copy of the piece of code, modify it, and leave the other copy unchanged. Sometimes it's a bug because it's inconsistent; sometimes it's a bug because the other copy lacks the feature for which the modification was made in the first copy. So, the lesson is: Try hard to avoid code duplication! * pygnulib/GLConfig.py line 802: Typo: Autmake -> Automake. Bruno