From: "Robin H. Johnson" <robbat2@gentoo.org>
To: "Robert P. J. Day" <rpjday@crashcourse.ca>,
Git Mailing List <git@vger.kernel.org>
Subject: Re: should any build system legitimately change any tracked files?
Date: Fri, 19 Jan 2018 18:45:20 +0000 [thread overview]
Message-ID: <robbat2-20180119T183103-843967451Z@orbis-terrarum.net> (raw)
In-Reply-To: <alpine.LFD.2.21.1801191247250.10222@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 2010 bytes --]
On Fri, Jan 19, 2018 at 12:51:52PM -0500, Robert P. J. Day wrote:
>
> just finished teaching a couple git courses and, after class, a
> student came up and described a rather weird problem -- in short:
>
> 1) before build, "git diff" shows nothing
> 2) do the standard build
> 3) suddenly, "git diff" shows some changes
>
> that's all the info i was given, but it *seems* clear that the build
> process itself was making changes to one or more tracked files.
>
> technically, i guess one can design a build system to do pretty
> much anything, but is it fair to say that this is a really poor design
> decision? admittedly, this isn't specifically a git question, but i'm
> open to opinions on something that strikes me as a bad idea.
I have seen what you describe, but it had a good cause:
1. The source repo contained some intermediate generated source,
eg foo.x -> foo.c -> foo.o
2. The output of the tool that did foo.a -> foo.c differed due to some
factor on the system (different version, different config in /etc etc).
3. The initial checkout caused the mtime of foo.c to be just older
newer than foo.x, so the build system decided to regen foo.c.
4. (optional) The makefile had conditional rules to skip the regen if the tool was
not present.
Until the tool output changed, even if the file was regenerated, it was
identical, so it didn't show up in diff.
What are the possible mistakes here?
- The intermediate source possibly should not be committed [depending on
the tool, this isn't always an option]
- The build system scripts (makefile etc) contains a mistake.
- Some final (non-intermediate/non-source) file was committed.
I've seen similar patterns for GNU Bison, autoconf, and lots of other
tools.
--
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail : robbat2@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 1113 bytes --]
prev parent reply other threads:[~2018-01-19 18:45 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-19 17:51 should any build system legitimately change any tracked files? Robert P. J. Day
2018-01-19 17:59 ` Randall S. Becker
2018-01-19 18:41 ` Theodore Ts'o
2018-01-19 18:45 ` Robin H. Johnson [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=robbat2-20180119T183103-843967451Z@orbis-terrarum.net \
--to=robbat2@gentoo.org \
--cc=git@vger.kernel.org \
--cc=rpjday@crashcourse.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).