From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS22989 209.51.188.0/24 X-Spam-Status: No, score=-3.5 required=3.0 tests=AWL,BAYES_00, DKIM_ADSP_CUSTOM_MED,DKIM_INVALID,DKIM_SIGNED, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, HTML_MESSAGE,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 34FFC1F4B4 for ; Sat, 3 Apr 2021 06:47:07 +0000 (UTC) Received: from localhost ([::1]:39176 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lSa3m-0005HI-9D for normalperson@yhbt.net; Sat, 03 Apr 2021 02:47:06 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:45148) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lSa3f-0005H8-9F for bug-gnulib@gnu.org; Sat, 03 Apr 2021 02:46:59 -0400 Received: from mail-pg1-x533.google.com ([2607:f8b0:4864:20::533]:43565) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lSa3d-0005s4-6R for bug-gnulib@gnu.org; Sat, 03 Apr 2021 02:46:58 -0400 Received: by mail-pg1-x533.google.com with SMTP id p12so796481pgj.10 for ; Fri, 02 Apr 2021 23:46:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fMhxdKf3KjDpvNTKbURRA4DP3/3LSUNPt0n7OEwxSDw=; b=AqQUDrqxKTAXIFwi48pVm5yA3w3JBqQpGKzgOHaYjYsBXBZDoaS07CkLHbOdlLiM3Y 3nlgyQZu315d9tppfaWrv+V6Na/H6bK6ylUNDZ7QIeM2GSqtfr1amoZG2jMHYK5u3yeP T+nNLdwM0cwwml7oErRXq0rprkOGIiw2IvmQyLxtAoN0Yb06Mfm720qp6iEsjAoZ9A3f CKYp6xBbuXn2khm3DIBJNbZ3jyVIusliamUilDAxgySi53ZqFbd03oOAvmHEruJlbojA lqLUNxKPS5A2oHGGivu8giOh5b/oOqaXJPgsCCsQZYrPHfwZHDliomYk9B6fto6t19gi wU1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fMhxdKf3KjDpvNTKbURRA4DP3/3LSUNPt0n7OEwxSDw=; b=YuC14/DMhUUTrDP7uJ2cmKWUxGfNEcLEAblr1cGOcnMTc7sk1fJ0YJV5Fo+ZgfHbVZ tSLPcMbSAXFC00HFY6IMd1BrRlZg3Cm8N5ov3bJX5EJg0t1H+r5Ys13hyU4rNJ36dfKP iIOHvzWKexUDQiUexKT5nArh+bW+FvfnJrOkbzM5xVIWNOK+TChTauSUtm2UqxPXqvRn ADYqzeBrLVTqRtoKOjoFgTDxklCZyG+UNZLwpQJmVTB9GVauewCKizXTScsFBOiM4qmj KiBjMxGGoH6HH5wIFD2fnfITPIQx/lfrzPsyBeO8GGgRCcSqSJHuZaMbKwo+++qqISq9 5ZiA== X-Gm-Message-State: AOAM532qkhQP6eo2xtswSjBG/HHoAks3x97QycFFMfBdz6Z8nxtnktLe tdRgG6NsjUnWKd6e7PZ7M1lzGOeweOz9hPDb6uY= X-Google-Smtp-Source: ABdhPJz3PksffY0MSiZNk+fdk7UkhElRUHLX314y/svwEe+PYfOIBgjkiR4NdQdGLNhvWy/h2PqpBZsd/j0xVR6YFpc= X-Received: by 2002:a62:7b0b:0:b029:1ef:1999:1d57 with SMTP id w11-20020a627b0b0000b02901ef19991d57mr15251461pfc.19.1617432415642; Fri, 02 Apr 2021 23:46:55 -0700 (PDT) MIME-Version: 1.0 References: <1884356.MhiIEz5669@omega> In-Reply-To: <1884356.MhiIEz5669@omega> From: =?UTF-8?Q?Marc_Nieper=2DWi=C3=9Fkirchen?= Date: Sat, 3 Apr 2021 08:46:44 +0200 Message-ID: Subject: Re: Autogenerated header files not included in .gitignore To: Bruno Haible Content-Type: multipart/alternative; boundary="00000000000095271e05bf0bd4c1" Received-SPF: pass client-ip=2607:f8b0:4864:20::533; envelope-from=marc.nieper@gmail.com; helo=mail-pg1-x533.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: =?UTF-8?Q?Marc_Nieper=2DWi=C3=9Fkirchen?= , bug-gnulib@gnu.org Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" --00000000000095271e05bf0bd4c1 Content-Type: text/plain; charset="UTF-8" Hi Bruno, thank you very much for your prompt reply. Am Sa., 3. Apr. 2021 um 01:00 Uhr schrieb Bruno Haible : 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 --00000000000095271e05bf0bd4c1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Bruno,

thank you very much for your prompt reply.
=
Am Sa.= , 3. Apr. 2021 um 01:00=C2=A0Uhr schrieb Bruno Haible <bruno@clisp.org>:

As f= ar as I know, there are two practices regarding .gitignore management:

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

=C2=A0 * Some developers don't want to think much when building a packa= ge.
=C2=A0 =C2=A0 They often build in the source dir. They want to have in .git= ignore
=C2=A0 =C2=A0 also the built files (*.o, alloca.h ... wctype.h, $(BUILT_SOU= RCES), etc.),
=C2=A0 =C2=A0 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?

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

Thank you for the detailed expl= anation. 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 disappear= s for me. If Gnulib is not going to be extended to support the second optio= n as well, it may be a good idea to add something along the lines of your r= emark above to section 3.12 of its manual ([1]).

If Gnulib is goi= ng to be extended to support the second option as well, I am not yet sure h= ow. The problem is that the same source tree would have to support both opt= ions to support both kinds of developers. This rules out the "--vc-fil= es" option because it would appear in "bootstrap.conf" (if &= quot;gnulib-tool" is not used directly), which isn't developer-spe= cific.
If dev= elopment 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

--00000000000095271e05bf0bd4c1--