Information for GNU Gnulib maintainers and contributors ******************************************************* Using git ========= * We don't use topic branches. Changes are usually small enough that they can be committed directly to the master branch, after appropriate testing. * We maintain stable branches, though, as described in the documentation: https://www.gnu.org/software/gnulib/manual/html_node/Stable-Branches.html When backporting a commit to a stable branch of the last year, be sure to update the copyright year of each modified file (since we don't run "make update-copyright" on the stable branches). * We use a linear git history — no merges. To work in this setting, it's recommended that you configure git with 'git config pull.rebase = true'. * Before pushing a commit, it is highly recommended that you review it in its entirety. The easiest ways to do so are * to run $ git format-patch -1 and then read the patch in an editor that has syntax-colouring of patch files, or * to run $ gitk * We update the ChangeLog by hand. The commit message is usually identical to the ChangeLog entry, with the date and author line removed, with the leading tabs removed, and with a blank line after the commit's summary line. In order to work efficiently with ChangeLog files, it is recommended that you configure git to use the git-merge-changelog driver; see the instructions in the lib/git-merge-changelog.c file. Note: This driver reasonably keeps the ChangeLog entries together; however, it does not always keep them in the order you would desire. For example, when you had prepared a commit, you try to "git push" it but that fails due to someone else's commit that came earlier, what you need to do is: 1. $ git pull 2. Verify that your ChangeLog entry is still the top-most one. 3. If it is not, then edit ChangeLog to move it to the top, and $ git commit --amend ChangeLog 4. $ gitk 5. $ git push * When you commit a contributor's patch, please - add a reasonable ChangeLog entry in the usual style (meaningful summary line and detailed change list), - as the date of the ChangeLog entry, use the current date (cf. https://www.gnu.org/prep/standards/html_node/Style-of-Change-Logs.html ). - if the contribution is so small that it does not require a copyright assignment (cf. https://www.gnu.org/prep/maintain/html_node/Legally-Significant.html ) add a line: Copyright-paperwork-exempt: Yes - use the 'git commit' option --author="Contributor Name " License Notices =============== In *.m4 files, use a notice like this: dnl Copyright (C) YEARS Free Software Foundation, Inc. dnl This file is free software; the Free Software Foundation dnl gives unlimited permission to copy and/or distribute it, dnl with or without modifications, as long as this notice is preserved. dnl This file is offered as-is, without any warranty. In lib/, tests/, build-aux/ files, except those that are shared with glibc, use the license notices from etc/license-notices/ . This avoids gratuitous differences in wording, as well misunderstandings when a license notice would say "This program ...". Test Suite ========== When adding a module, add a unit test module as well. This is our best chance to catch portability problems. A unit test can have many sub-tests. Try to make the sub-tests independent of each other, so that it becomes easy to disable some sub-tests by enclosing them in #if 0 ... #endif. The main() function's exit code meaning is: - 0: PASS - 77: SKIP; you should print the reason why the test is skipped. - 99: ERROR, i.e. test framework error - any other exit code < 126: FAIL In tests that #include "macros.h" and use the ASSERT macro: The main() function should, before it returns 0 (for PASS) or 77 (for SKIP) test the value of test_exit_status and return that instead. So: - not return 0; but instead return test_exit_status; - not return result; // where result can be 0 or 1 but instead return (result ? result : test_exit_status); - not fputs ("Skipping test: \n", stderr); return 77; but instead if (test_exit_status != EXIT_SUCCESS) return test_exit_status; fputs ("Skipping test: \n", stderr); return 77; Only at the beginning of the main() function, when ASSERT has not yet been invoked, we know that test_exit_status must be zero and can therefore write fputs ("Skipping test: \n", stderr); return 77; directly. Maintaining high quality ======================== It is a good idea to occasionally create a testdir of all of Gnulib: $ rm -rf ../testdir-all; \ ./gnulib-tool --create-testdir --dir=../testdir-all --with-c++-tests --without-privileged-tests \ `./all-modules` and test this directory on various platforms: - Linux/glibc systems, - Linux/musl systems, - macOS, - FreeBSD, - NetBSD, - OpenBSD, - AIX, - Solaris 10 and 11, - Cygwin, - Haiku, - Android, - and other platforms of your choice. There are two continuous integrations that regularly perform this testing: * On a Linux/glibc system only: https://gitlab.com/gnulib/gnulib-ci This one will catch only the most blatant mistakes. * On many platforms: https://github.com/gnu-gnulib/ci-testdir-check/actions This one runs on many platforms, currently (as of June 2024): - Ubuntu GNU/Linux 22.04 - CentOS GNU/Linux 7 - Alpine Linux - macOS 11, 12, 13 (all x86_64) - macOS 14 (arm64) - FreeBSD 14.0 - NetBSD 10.0 - OpenBSD 7.5 - Solaris 11.4 - Solaris 11 OmniOS - Cygwin 3.3.6 (32 bit) and 3.5.3 (64 bit) - mingw (32 bit and 64 bit) - MSVC (32 bit and 64 bit) and also - on Ubuntu GNU/Linux 22.04 with clang's UBSAN and ASAN sanitizers. This one catches real portability problems. Note that the following platforms are not covered and thus still require occasional manual testing: - AIX - Solaris 10 - Haiku - Android - and other platforms of your choice. If you want to test changes on a few modules only, say M1 ... Mn, a 'testdir-all' may be overkill. For this case, you can create a testdir of all potentially affected modules: $ rm -rf ../testdir; \ ./gnulib-tool --create-testdir --dir=../testdir --with-c++-tests --without-privileged-tests \ `./gnulib-tool --extract-recursive-dependents M1 ... Mn` and then test this directory on various platforms. Coding Style ============ For C source code: * Follow the portability guidelines https://www.gnu.org/software/gnulib/manual/html_node/Portability-guidelines.html * Use mixed declarations and statements, as appropriate. (This is supported since C99.) * Note: You can't put a label before a declaration, such as in retry: int foo = ...; This is supported only in C23 or newer. Instead, add an empty statement: retry: ; int foo = ...; Similarly, you can't put a declaration immediately after a case label, such as in case 1: int foo = ...; ... break; Again, this is supported only in C23 or newer. Instead, use a sub-block: case 1: { int foo = ...; ... } break; * In function definitions and blocks, the pre-C99 style "declare all variables upfront" is discouraged. Instead, the following style elements are encouraged (for local non-static variables): - Move the declaration of a variable to its initialization. - Reduce the scope of variables: . If a variable is only used in a sub-block, declare it in that sub-block. . If a variable is only used in several sub-blocks and has a separate initialization in each of the sub-blocks, declare it in each of these sub-blocks. It's actually several independent variables. . If a variable is only used in a small part of a function definition or block (say, 1/3 of it or less), you may surround that part (including the variable's initialization) with braces, so that it becomes clear that the variable is not used in the rest of the function / block. - Usually, try to declare and initialize variables right when they are needed for the first time, not several computation steps before. The rationale is: - It follows the general principle "Put related things close together." - A function with 3 blocks that each has 4 variables is easier to understand than a function that has 12 variables, and where the reader has to find out which variable is used where. - Variables may represent state, and it is the state and the control flow that contribute to the complexity of a function. Only static variables are better kept declared upfront in a function or block. Acceptable use of LLM generated code ==================================== General-purpose LLMs as well as LLMs specialized for software programming can produce ready-to-use and, in many cases, actually working code. We need to avoid two problems with that: * Copyright and license issue: An LLM may regurgitate a piece of copyrighted code without the copyright header, thus violating the code's license. (Most code licenses require that the copyright header remains intact when the code is copied or becomes the basis of derivative works.) * Maintainability issues: Such generated code has initially not been reviewed by a human programmer. It is often greater in size than what a careful programmer would write. Sometimes it also lacks comments. People who use "vibe coding" often also observe that the code is of lower quality. Where software in general can be qualified as for long-term use vs. short-term use, vibe coding tends to be more suitable for short-term used software. To this end: 1) Code derived from an LLM must respect copyrights and licenses in the source material that the LLM is based on. For a traditional, single LLM prompt this means a code response must be limited in size: it must be at most 5 lines long. 2) As a submitter, you assert that you have reviewed such code that you submit. Rule 1 guarantees that the LLM generated code size is smaller than the "legally significant for copyright purposes" threshold, see https://www.gnu.org/prep/maintain/html_node/Legally-Significant.html Rule 2 encourages you to not submit unreviewed garbage. Warning Options =============== For packages that use Gnulib, we recommend to use the 'warnings' or 'manywarnings' module, as documented in https://www.gnu.org/software/gnulib/manual/html_node/warnings.html https://www.gnu.org/software/gnulib/manual/html_node/manywarnings.html When building Gnulib testdirs, e.g. when preparing a Gnulib patch, there are three possible approaches: * The simplest approach, which warns about the most common mistakes, is to use GCC's -Wall option, both for C and C++ compilation units. Just set $ ./configure CPPFLAGS="-Wall" $ make You should generally fix all compiler warnings that you see from this approach. * If you are developing on a glibc system and have GCC version 15 binaries available, here's a recipe that will find more mistakes, but is nearly as easy to use. Here, different warning options are needed for C and for C++: $ WARN_GCC15=`echo ' -fanalyzer -Wall -Warith-conversion -Wcast-align=strict -Wdate-time -Wduplicated-cond -Wextra -Wflex-array-member-not-at-end -Wformat-signedness -Winit-self -Winvalid-pch -Wlogical-op -Wmaybe-musttail-local-addr -Wmissing-include-dirs -Wopenmp-simd -Woverlength-strings -Wpacked -Wpointer-arith -Wsuggest-final-methods -Wsuggest-final-types -Wsync-nand -Wsystem-headers -Wtrampolines -Wuninitialized -Wunknown-pragmas -Wvariadic-macros -Wvector-operation-performance -Wwrite-strings -Warray-bounds=2 -Wattribute-alias=2 -Wformat-overflow=2 -Wformat-truncation=2 -Wshift-overflow=2 -Wunused-const-variable=2 -Wvla-larger-than=4031 -Wno-empty-body -Wno-analyzer-allocation-size -Wno-analyzer-fd-double-close -Wno-analyzer-double-fclose -Wno-analyzer-double-free -Wno-analyzer-fd-leak -Wno-analyzer-fd-use-after-close -Wno-analyzer-fd-use-without-check -Wno-analyzer-free-of-non-heap -Wno-analyzer-malloc-leak -Wno-analyzer-mismatching-deallocation -Wno-analyzer-null-argument -Wno-analyzer-null-dereference -Wno-analyzer-out-of-bounds -Wno-analyzer-possible-null-argument -Wno-analyzer-possible-null-dereference -Wno-analyzer-use-after-free -Wno-analyzer-use-of-pointer-in-stale-stack-frame -Wno-analyzer-use-of-uninitialized-value -Wno-analyzer-va-arg-type-mismatch -Wno-attribute-warning -Wno-cast-align -Wno-clobbered -Wno-dangling-pointer -Wno-format -Wno-implicit-fallthrough -Wno-maybe-uninitialized -Wno-missing-field-initializers -Wno-restrict -Wno-sign-compare -Wno-switch -Wno-type-limits -Wno-unused-parameter ' | tr -d '\n' | sed -e 's/ */ /g'` $ WARN_CFLAGS_GCC15="$WARN_GCC15 -Wmissing-variable-declarations -Wnested-externs -Wshadow=local -Wno-discarded-qualifiers" $ WARN_CXXFLAGS_GCC15="$WARN_GCC15 -Wno-cpp" $ ./configure CFLAGS="-O2 -g $WARN_CFLAGS_GCC15" CXXFLAGS="-O2 -g $WARN_CXXFLAGS_GCC15" $ make You should generally fix all compiler warnings that you see from this approach, or report when this approach produced a pointless warning (so that we can fix the value of WARN_GCC15 above). * If you are developing on a glibc system and have GCC version 15 binaries available: Here's a recipe that will find even more mistakes, but it requires that you are willing to filter out and ignore pointless warnings. $ WARN_GCC15=`echo ' -fanalyzer -Wall -Warith-conversion -Wcast-align=strict -Wdate-time -Wduplicated-cond -Wextra -Wflex-array-member-not-at-end -Wformat-signedness -Winit-self -Winvalid-pch -Wlogical-op -Wmaybe-musttail-local-addr -Wmissing-include-dirs -Wnull-dereference -Wopenmp-simd -Woverlength-strings -Wpacked -Wpointer-arith -Wsuggest-attribute=format -Wsuggest-final-methods -Wsuggest-final-types -Wsync-nand -Wsystem-headers -Wtrampolines -Wuninitialized -Wunknown-pragmas -Wvariadic-macros -Wvector-operation-performance -Wwrite-strings -Warray-bounds=2 -Wattribute-alias=2 -Wformat-overflow=2 -Wformat=2 -Wformat-truncation=2 -Wimplicit-fallthrough=5 -Wshift-overflow=2 -Wunused-const-variable=2 -Wvla-larger-than=4031 -Wno-empty-body -Wno-analyzer-double-fclose -Wno-analyzer-double-free -Wno-analyzer-free-of-non-heap -Wno-analyzer-malloc-leak -Wno-analyzer-null-argument -Wno-analyzer-null-dereference -Wno-analyzer-use-after-free -Wno-attribute-warning -Wno-cast-align -Wno-clobbered -Wno-format-nonliteral -Wno-sign-compare -Wno-type-limits -Wno-unused-parameter ' | tr -d '\n' | sed -e 's/ */ /g'` $ WARN_CFLAGS_GCC15="$WARN_GCC15 -Wmissing-variable-declarations -Wnested-externs -Wshadow=local" $ WARN_CXXFLAGS_GCC15="$WARN_GCC15 -Wno-cpp" $ ./configure CFLAGS="-O2 -g $WARN_CFLAGS_GCC15" CXXFLAGS="-O2 -g $WARN_CXXFLAGS_GCC15" $ make With this approach, use your own judgement whether to fix warnings arising from your new code or not. Do *not* submit patches to silence warnings from existing code: - For these warnings, often the cure will be worse than the disease. - Some of the warnings are false positives. Rather than silencing these warnings, we prefer to report them in the GCC bug tracker and wait until they are fixed in a future GCC release. Similarly, for clang version 20 you can use the following recipe, that uses selected warning options from https://releases.llvm.org/20.1.0/tools/clang/docs/DiagnosticsReference.html : $ WARN_CLANG20=`echo ' -Wall -Wanon-enum-enum-conversion -Warc-repeated-use-of-weak -Warray-bounds-pointer-arithmetic -Warray-parameter -Watomic-properties -Wauto-decl-extensions -Wbinary-literal -Wbit-int-extension -Wbitfield-enum-conversion -Wbitwise-op-parentheses -Wbool-operation -Wc++-compat -Wc23-compat -Wc23-extensions -Wc2x-compat -Wc2x-extensions -Wc23-extensions -Wc99-compat -Wc99-designator -Wc99-extensions -Wcalled-once-parameter -Wcast-function-type -Wchar-subscripts -Wcomment -Wcompletion-handler -Wcomplex-component-init -Wcompound-token-split -Wconsumed -Wconversion -Wcstring-format-directive -Wcuda-compat -Wdate-time -Wdelimited-escape-sequence-extension -Wdeprecated -Wdeprecated-dynamic-exception-spec -Wdeprecated-implementations -Wdeprecated-this-capture -Wdeprecated-writable-strings -Wdirect-ivar-access -Wdocumentation -Wdocumentation-deprecated-sync -Wdocumentation-html -Wdocumentation-pedantic -Wdocumentation-unknown-command -Wdollar-in-identifier-extension -Wduplicate-decl-specifier -Wduplicate-enum -Wduplicate-method-arg -Wduplicate-method-match -Wdynamic-exception-spec -Wembedded-directive -Wempty-init-stmt -Wempty-translation-unit -Wenum-compare-conditional -Wenum-conversion -Wenum-enum-conversion -Wenum-float-conversion -Wexit-time-destructors -Wexpansion-to-defined -Wexplicit-ownership-type -Wextra -Wextra-semi -Wflexible-array-extensions -Wfloat-overflow-conversion -Wfloat-zero-conversion -Wfor-loop-analysis -Wformat -Wformat-pedantic -Wformat-type-confusion -Wformat=2 -Wfour-char-constants -Wframe-address -Wfuse-ld-path -Wfuture-attribute-extensions -Wgcc-compat -Wgnu -Wgnu-anonymous-struct -Wgnu-auto-type -Wgnu-case-range -Wgnu-complex-integer -Wgnu-compound-literal-initializer -Wgnu-conditional-omitted-operand -Wgnu-designator -Wgnu-empty-initializer -Wgnu-empty-struct -Wgnu-flexible-array-initializer -Wgnu-flexible-array-union-member -Wgnu-folding-constant -Wgnu-imaginary-constant -Wgnu-label-as-value -Wgnu-line-marker -Wgnu-null-pointer-arithmetic -Wgnu-offsetof-extensions -Wgnu-pointer-arith -Wgnu-redeclared-enum -Wgnu-statement-expression -Wgnu-statement-expression-from-macro-expansion -Wgnu-union-cast -Wgnu-zero-line-directive -Wgnu-zero-variadic-macro-arguments -Wheader-hygiene -Widiomatic-parentheses -Wignored-qualifiers -Wimplicit -Wimplicit-fallthrough -Wimplicit-fallthrough-per-function -Wimplicit-function-declaration -Wimplicit-int -Wimplicit-retain-self -Wimport-preprocessor-directive-pedantic -Wincomplete-module -Winconsistent-missing-destructor-override -Winfinite-recursion -Wint-in-bool-context -Winvalid-or-nonexistent-directory -Winvalid-utf8 -Wkeyword-macro -Wlanguage-extension-token -Wlocal-type-template-args -Wlogical-op-parentheses -Wlong-long -Wloop-analysis -Wmain -Wmax-tokens -Wmethod-signatures -Wmicrosoft -Wmicrosoft-anon-tag -Wmicrosoft-charize -Wmicrosoft-comment-paste -Wmicrosoft-cpp-macro -Wmicrosoft-end-of-file -Wmicrosoft-enum-value -Wmicrosoft-exception-spec -Wmicrosoft-fixed-enum -Wmicrosoft-flexible-array -Wmicrosoft-redeclare-static -Wmisleading-indentation -Wmismatched-tags -Wmissing-braces -Wmissing-method-return-type -Wmost -Wmove -Wnested-anon-types -Wnewline-eof -Wnon-gcc -Wnon-modular-include-in-framework-module -Wnon-modular-include-in-module -Wnon-virtual-dtor -Wnonportable-system-include-path -Wnull-pointer-arithmetic -Wnull-pointer-subtraction -Wnullability-extension -Wnullable-to-nonnull-conversion -Wopenmp -Wover-aligned -Woverlength-strings -Woverloaded-virtual -Woverriding-method-mismatch -Wpacked -Wpacked-non-pod -Wparentheses -Wpedantic -Wpedantic-core-features -Wpessimizing-move -Wpointer-arith -Wpoison-system-directories -Wpragma-pack -Wpragma-pack-suspicious-include -Wpragmas -Wpre-c11-compat -Wpre-c23-compat -Wpre-c2x-compat -Wpre-c2y-compat -Wpre-openmp-51-compat -Wprofile-instr-missing -Wquoted-include-in-framework-header -Wrange-loop-analysis -Wrange-loop-bind-reference -Wrange-loop-construct -Wreceiver-forward-class -Wredundant-move -Wredundant-parens -Wreorder -Wreorder-ctor -Wreserved-attribute-identifier -Wreserved-user-defined-literal -Wretained-language-linkage -Wselector -Wselector-type-mismatch -Wself-assign -Wself-assign-overloaded -Wself-move -Wsemicolon-before-method-body -Wshadow-all -Wshadow-field -Wshadow-field-in-constructor -Wshadow-field-in-constructor-modified -Wshadow-uncaptured-local -Wshift-sign-overflow -Wsigned-enum-bitfield -Wsometimes-uninitialized -Wsource-uses-openacc -Wsource-uses-openmp -Wspir-compat -Wstatic-in-inline -Wstrict-potentially-direct-selector -Wstrict-selector-match -Wstring-concatenation -Wstring-conversion -Wsuggest-destructor-override -Wsuggest-override -Wsuper-class-method-mismatch -Wtautological-bitwise-compare -Wtautological-compare -Wtautological-constant-in-range-compare -Wtautological-negation-compare -Wtautological-overlap-compare -Wtautological-type-limit-compare -Wtautological-unsigned-char-zero-compare -Wtautological-unsigned-enum-zero-compare -Wtautological-unsigned-zero-compare -Wtautological-value-range-compare -Wthread-safety -Wthread-safety-analysis -Wthread-safety-attributes -Wthread-safety-beta -Wthread-safety-negative -Wthread-safety-precise -Wthread-safety-reference -Wthread-safety-verbose -Wtype-limits -Wunaligned-access -Wundeclared-selector -Wundef-prefix -Wundefined-func-template -Wundefined-internal-type -Wundefined-reinterpret-cast -Wunguarded-availability -Wuninitialized -Wuninitialized-const-reference -Wunknown-pragmas -Wunnamed-type-template-args -Wunneeded-internal-declaration -Wunneeded-member-function -Wunreachable-code-fallthrough -Wunreachable-code-loop-increment -Wunsupported-dll-base-class-template -Wunused -Wunused-but-set-parameter -Wunused-but-set-variable -Wunused-const-variable -Wunused-exception-parameter -Wunused-function -Wunused-label -Wunused-lambda-capture -Wunused-local-typedef -Wunused-member-function -Wunused-private-field -Wunused-property-ivar -Wunused-template -Wunused-variable -Wvariadic-macros -Wvector-conversion -Wvla-cxx-extension -Wweak-template-vtables -Wweak-vtables -Wzero-length-array -Wno-bitwise-instead-of-logical -Wno-c11-extensions -Wno-cast-function-type-strict -Wno-float-conversion -Wno-format-nonliteral -Wno-gnu-include-next -Wno-implicit-float-conversion -Wno-implicit-int-conversion -Wno-implicit-int-float-conversion -Wno-include-next-absolute-path -Wno-missing-field-initializers -Wno-reserved-macro-identifier -Wno-shadow -Wno-shorten-64-to-32 -Wno-sign-compare -Wno-sign-conversion -Wno-strict-prototypes -Wno-switch -Wno-unused-parameter -Wno-tautological-constant-out-of-range-compare -Wno-tautological-type-limit-compare -Wno-tautological-unsigned-zero-compare -Wno-tautological-value-range-compare -Wno-unused-command-line-argument -Wno-user-defined-warnings ' | tr -d '\n' | sed -e 's/ */ /g'` $ ./configure CFLAGS="-O2 -g $WARN_CLANG20" CXXFLAGS="-O2 -g $WARN_CLANG20" $ make Again, use your own judgement to determine whether to fix or ignore a specific warning. Maintaining link dependencies ============================= Each module has a section "Link:", that contains the linker options that a program, that makes use of the module, needs to use, in order to avoid a link error. Unless empty, this field contains one or more variable references, because linker options are platform dependent. A gnulib-tool invocation lists these linker options to the package maintainer, so that they can make use of these options in the *_LDFLAGS in their package's Makefile.am. Of course, the unit tests uses these linker options. Often the link dependencies for module 'foo' follows this naming convention: $(FOO_LIB). For example, there are variables references $(MBRTOWC_LIB) $(SETLOCALE_LIB). Typically, when you make a code change in a module and accordingly define a variable for its linker options in the corresponding *.m4 file, you also need to update the linker options of all modules that depend on it: $ ./gnulib-tool --extract-dependents foo and the linker options of all modules that depend on these, etc.: $ ./gnulib-tool --extract-recursive-dependents foo The use of a variable per module avoids the need for an avalanche of changes. When you notice a link error of a program, you typically fix it in three steps: 1. Ask "Which library does the program need to link with?" You answer this by consulting documentation and man pages, as well as by use of "nm --dynamic /lib/libxyz.so". 2. Ask "From which autoconf variable do I get this library option?" You answer this by searching the *LIB* values in config.status: $ grep LIB config.status 3. Finally you add a reference to that variable to the *_LIB variable of your module. Or, if your module does not have such a variable so far, you introduce such a variable and make sure to update all dependents to make use of it (see above). Information for gnulib-tool maintenance *************************************** Running the unit tests ====================== The unit tests of gnulib-tool reside in the maint-tools repository, that is a satellite repository of the main gnulib repository. Instructions how to obtain it are in https://savannah.gnu.org/git/?group=gnulib . To run the unit tests of gnulib-tool.sh: $ cd maint-tools/gnulib-tool-tests/ $ GNULIB_TOOL_IMPL=sh ./test-all.sh To run the unit tests of gnulib-tool.py: $ cd maint-tools/gnulib-tool-tests/ $ GNULIB_TOOL_IMPL=py ./test-all.sh It is *mandatory* that you run the test suite before pushing any change to gnulib-tool.sh or gnulib-tool.py! If you fail to do so, and your change contains a bug, it will start to affect users immediately. Debugging the Python implementation of gnulib-tool ================================================== With Eclipse and PyDev as IDE ----------------------------- * Download and configuration: - Eclipse IDE from https://www.eclipse.org/downloads/packages/ (either the build for Java or for C/C++ should work fine; either use the Eclipse Installer program at the top of the page, or one of the individual download links below). - PyDev from https://www.pydev.org/download.html section "Install as Plugin". (Don't use LiClipse, since the license costs money.) - Follow https://www.pydev.org/manual_101_install.html, replacing http://www.pydev.org/updates with https://www.pydev.org/updates - Once installed, restart the IDE. - Window > Preferences > PyDev > Interpreters > Python Interpreter: New > path: /usr/bin/python3 - Window > Preferences > PyDev > Editor > Code Analysis: Others > Redefinition of builtin symbols: Ignore * Create a project: Let GNULIB_DIR be my gnulib checkout. - File > New > Project... > PyDev > PyDev Project. Call it 'gnulib-tool'. Note that this is a project inside the Eclipse workspace, so far unrelated to the GNULIB_DIR. - Popup menu > New > Link to Existing Source Name: gnulib Path: * Create a run configuration: - Run > Run Configurations... > Python Run Popup menu > New configuration Name: gnulib-tool.py Main > Project: gnulib-tool Main > Main Module: ${workspace_loc:gnulib-tool/gnulib/.gnulib-tool.py} Arguments > Program arguments: --help - Test it: Run this configuration. * Create a debug configuration: - Run > Debug Configurations... > gnulib-tool.py Popup menu > Duplicate - In the duplicate, set Arguments > Working directory: /tmp/oath-toolkit/lib Arguments > Program arguments: --add-import * Debug it: - Open GLImport.py. - On the left-hand border of this editor, do "Add breakpoint". - Run > Debug Configurations... > pick the duplicate. Press Debug. Maintaining high quality ======================== There is a continuous integration of gnulib-tool.py that runs the unit tests, at https://gitlab.com/gnulib/gnulib-tool-ci/ .