Autogenerated header files not included in .gitignore

Autogenerated header files not included in .gitignore

[Marc Nieper-Wißkirchen]

[-- Attachment #1: Type: text/plain, Size: 426 bytes --]

A number of autogenerated header files are not added to ".gitignore" in
"$source_base".

For example, in a current project of mine,

$ git status

shows

lib/alloca.h
lib/fcntl.h
lib/inttypes.h
lib/langinfo.h
lib/limits.h
lib/locale.h
lib/signal.h
lib/stdio.h
lib/stdlib.h
lib/string.h
lib/sys/
lib/time.h
lib/unistd.h
lib/wchar.h
lib/wctype.h

Currently, Gnulib only adds "in"-files like "alloca.h.in" to ".gitignore".

Marc

[-- Attachment #2: Type: text/html, Size: 1429 bytes --]

Re: Autogenerated header files not included in .gitignore

[Bruno Haible]

Hi Marc, all,

> A number of autogenerated header files are not added to ".gitignore" in
> "$source_base".
> 
> For example, in a current project of mine,
> 
> $ git status
> 
> shows
> 
> lib/alloca.h
> lib/fcntl.h
> lib/inttypes.h
> lib/langinfo.h
> lib/limits.h
> lib/locale.h
> lib/signal.h
> lib/stdio.h
> lib/stdlib.h
> lib/string.h
> lib/sys/
> lib/time.h
> lib/unistd.h
> lib/wchar.h
> lib/wctype.h
> 
> Currently, Gnulib only adds "in"-files like "alloca.h.in" to ".gitignore".

As far as I know, there are two practices regarding .gitignore management:

  * Some developers want a very clean source directory at all times.
    They always to VPATH builds. They want to have in .gitignore the
    files brought in by Automake and Gnulib, but not the built files
    (*.o, alloca.h ... wctype.h, $(BUILT_SOURCES), etc.)

  * Some developers don't want to think much when building a package.
    They often build in the source dir. They want to have in .gitignore
    also the built files (*.o, alloca.h ... wctype.h, $(BUILT_SOURCES), etc.),
    even the log files left my "make check".

Gnulib, so far, is tailored for the first practice. How, would you say,
should we handle these two (incompatible) expectations?

  - A gnulib-tool option --vc-files=... (two possible options)?
  - Let gnulib-tool guess which of the two possible options is desired,
    based on the existing contents of the .gitignore files?
  - Other ideas?

Bruno

Re: Autogenerated header files not included in .gitignore

[Marc Nieper-Wißkirchen]

[-- Attachment #1: Type: text/plain, Size: 2199 bytes --]

Hi Bruno,

thank you very much for your prompt reply.

Am Sa., 3. Apr. 2021 um 01:00 Uhr schrieb Bruno Haible <bruno@clisp.org>:

As far as I know, there are two practices regarding .gitignore management:
>
>   * Some developers want a very clean source directory at all times.
>     They always to VPATH builds. They want to have in .gitignore the
>     files brought in by Automake and Gnulib, but not the built files
>     (*.o, alloca.h ... wctype.h, $(BUILT_SOURCES), etc.)
>
>   * Some developers don't want to think much when building a package.
>     They often build in the source dir. They want to have in .gitignore
>     also the built files (*.o, alloca.h ... wctype.h, $(BUILT_SOURCES),
> etc.),
>     even the log files left my "make check".
>
> Gnulib, so far, is tailored for the first practice. How, would you say,
> should we handle these two (incompatible) expectations?
>
>   - A gnulib-tool option --vc-files=... (two possible options)?
>   - Let gnulib-tool guess which of the two possible options is desired,
>     based on the existing contents of the .gitignore files?
>   - Other ideas?
>

Thank you for the detailed explanation. As you will have deduced, I have
been using the second option, the build in the source tree.

I can switch to the first option so that the issue disappears for me. If
Gnulib is not going to be extended to support the second option as well, it
may be a good idea to add something along the lines of your remark above to
section 3.12 of its manual ([1]).

If Gnulib is going to be extended to support the second option as well, I
am not yet sure how. The problem is that the same source tree would have to
support both options to support both kinds of developers. This rules out
the "--vc-files" option because it would appear in "bootstrap.conf" (if
"gnulib-tool" is not used directly), which isn't developer-specific.

If development model #2 is going to be supported, the only feasible option
I see here would be to add the autogenerated header files non-conditionally
(and to rely on user-provided ".gitignore" fragments to ignore object
files, log files, etc.)

--

[1] https://www.gnu.org/software/gnulib/manual/html_node/VCS-Issues.html

[-- Attachment #2: Type: text/html, Size: 3594 bytes --]

Re: Autogenerated header files not included in .gitignore

[Bruno Haible]

Hi Marc,

> If Gnulib is going to be extended to support the second option as well

That's what I'm suggesting, because the second way to manage files appears
to be the majority one.

> I am not yet sure how. The problem is that the same source tree would have to
> support both options to support both kinds of developers.

No, when .gitignore lists all built files, this holds for all developers.

In a project where some developers want the first approach and some want
the second one, the built files need to be listed in the .git/info/exclude
file, not in .gitignore. But since .git/info/exclude is not shared among
developers, it is tedious for every developer to maintain their own
.git/info/exclude list. Therefore I don't think this "mixed" model is
widely used.

Bruno

Re: Autogenerated header files not included in .gitignore

[Marc Nieper-Wißkirchen]

[-- Attachment #1: Type: text/plain, Size: 1245 bytes --]

Hi Bruno,

Am Sa., 3. Apr. 2021 um 12:05 Uhr schrieb Bruno Haible <bruno@clisp.org>:

> Hi Marc,
>
> > If Gnulib is going to be extended to support the second option as well
>
> That's what I'm suggesting, because the second way to manage files appears
> to be the majority one.
>
> > I am not yet sure how. The problem is that the same source tree would
> have to
> > support both options to support both kinds of developers.
>
> No, when .gitignore lists all built files, this holds for all developers.
>

Right. This is even more fundamental than my point about "bootstrap.conf".


> In a project where some developers want the first approach and some want
> the second one, the built files need to be listed in the .git/info/exclude
> file, not in .gitignore. But since .git/info/exclude is not shared among
> developers, it is tedious for every developer to maintain their own
> .git/info/exclude list. Therefore I don't think this "mixed" model is
> widely used.
>

Would it do much harm if ".gitignore" included all built files even for
developers that work in a dedicated build tree?

Adding all built files automatically to ".gitignore" may, however, be
non-trivial because file extensions (like "$EXE") can vary from system to
system.

[-- Attachment #2: Type: text/html, Size: 2243 bytes --]

Re: Autogenerated header files not included in .gitignore

[Bruno Haible]

Marc Nieper-Wißkirchen wrote:
> Would it do much harm if ".gitignore" included all built files even for
> developers that work in a dedicated build tree?

The developers who are using the first approach will not like this.

Bruno

Re: Autogenerated header files not included in .gitignore

[Marc Nieper-Wißkirchen]

[-- Attachment #1: Type: text/plain, Size: 715 bytes --]

I have been experimenting a bit with building in a dedicated build
directory. Nevertheless, I still end up with artefacts in the source
directory, which are not covered by Gnulib's .gitignore files, for example
with:

lib/iconv_open-aix.h
lib/iconv_open-hpux.h
lib/iconv_open-irix.h
lib/iconv_open-osf.h
lib/iconv_open-solaris.h
lib/iconv_open-zos.h

Thanks,

Marc

Am Sa., 3. Apr. 2021 um 12:22 Uhr schrieb Bruno Haible <bruno@clisp.org>:

> Marc Nieper-Wißkirchen wrote:
> > Would it do much harm if ".gitignore" included all built files even for
> > developers that work in a dedicated build tree?
>
> The developers who are using the first approach will not like this.
>
> Bruno
>
>

[-- Attachment #2: Type: text/html, Size: 1485 bytes --]

Re: Autogenerated header files not included in .gitignore

[Marc Nieper-Wißkirchen]

[-- Attachment #1: Type: text/plain, Size: 1264 bytes --]

PS:

Alternatively to the suggestion of a new gnulib-tool option
"--vc-files=...", one could also make Gnulib's behavior dependent on the
presence of a file, say ".gnulib-in-tree-build". This has the advantage
that no source files have to be changed to switch from one behavior to the
other but that, in principle, a developer can decide to switch to in-tree
builds by touching such a file locally.

Am Fr., 9. Apr. 2021 um 13:16 Uhr schrieb Marc Nieper-Wißkirchen <
marc.nieper+gnu@gmail.com>:

> I have been experimenting a bit with building in a dedicated build
> directory. Nevertheless, I still end up with artefacts in the source
> directory, which are not covered by Gnulib's .gitignore files, for example
> with:
>
> lib/iconv_open-aix.h
> lib/iconv_open-hpux.h
> lib/iconv_open-irix.h
> lib/iconv_open-osf.h
> lib/iconv_open-solaris.h
> lib/iconv_open-zos.h
>
> Thanks,
>
> Marc
>
> Am Sa., 3. Apr. 2021 um 12:22 Uhr schrieb Bruno Haible <bruno@clisp.org>:
>
>> Marc Nieper-Wißkirchen wrote:
>> > Would it do much harm if ".gitignore" included all built files even for
>> > developers that work in a dedicated build tree?
>>
>> The developers who are using the first approach will not like this.
>>
>> Bruno
>>
>>

[-- Attachment #2: Type: text/html, Size: 2537 bytes --]