{"thread":{"id":"47645","subject":"should any build system legitimately change any tracked files?","startedAt":"2018-01-19T17:52:00Z","lastAt":"2018-01-19T18:45:33Z","messageCount":4,"participants":["Robert P. J. Day","Randall S. Becker","Theodore Ts'o","Robin H. Johnson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"336910","messageId":"alpine.LFD.2.21.1801191247250.10222@localhost.localdomain","threadId":"47645","inReplyTo":null,"subject":"should any build system legitimately change any tracked files?","fromName":"Robert P. J. Day","fromEmail":"rpjday@crashcourse.ca","sentAt":"2018-01-19T17:51:52Z","receivedAt":"2018-01-19T17:52:00Z","isPatch":false,"sender":{"key":"rpjday@crashcourse.ca","avatar":"https://avatars.githubusercontent.com/u/226084077?v=4"},"body":"\n  just finished teaching a couple git courses and, after class, a\nstudent came up and described a rather weird problem -- in short:\n\n  1) before build, \"git diff\" shows nothing\n  2) do the standard build\n  3) suddenly, \"git diff\" shows some changes\n\nthat's all the info i was given, but it *seems* clear that the build\nprocess itself was making changes to one or more tracked files.\n\n  technically, i guess one can design a build system to do pretty\nmuch anything, but is it fair to say that this is a really poor design\ndecision? admittedly, this isn't specifically a git question, but i'm\nopen to opinions on something that strikes me as a bad idea.\n\nrday\n"},{"id":"336913","messageId":"005b01d3914f$3441fca0$9cc5f5e0$@nexbridge.com","threadId":"47645","inReplyTo":"alpine.LFD.2.21.1801191247250.10222@localhost.localdomain","subject":"RE: should any build system legitimately change any tracked files?","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2018-01-19T17:59:03Z","receivedAt":"2018-01-19T17:59:57Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On January 19, 2018 12:52 PM, Robert P. J. Day wrote:\n>   just finished teaching a couple git courses and, after class, a student\ncame\n> up and described a rather weird problem -- in short:\n> \n>   1) before build, \"git diff\" shows nothing\n>   2) do the standard build\n>   3) suddenly, \"git diff\" shows some changes\n> \n> that's all the info i was given, but it *seems* clear that the build\nprocess itself\n> was making changes to one or more tracked files.\n> \n>   technically, i guess one can design a build system to do pretty much\n> anything, but is it fair to say that this is a really poor design\ndecision?\n> admittedly, this isn't specifically a git question, but i'm open to\nopinions on\n> something that strikes me as a bad idea.\n\nDepends what you're up to.  Changing the source repository content is\nprobably bad. Adding tags may not be. Also, updating a separate repository\nto include build information (a.k.a dependency tracking between source and\nobject commits) can be very useful for managing production builds and\nenvironments.\n\nCheers,\nRandall\n\n-- Brief whoami:\n NonStop developer since approximately 211288444200000000\n UNIX developer since approximately 421664400\n-- In my real life, I talk too much.\n\n\n\n"},{"id":"336919","messageId":"20180119184128.GA643@thunk.org","threadId":"47645","inReplyTo":"alpine.LFD.2.21.1801191247250.10222@localhost.localdomain","subject":"Re: should any build system legitimately change any tracked files?","fromName":"Theodore Ts'o","fromEmail":"tytso@mit.edu","sentAt":"2018-01-19T18:41:28Z","receivedAt":"2018-01-19T18:41:36Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Fri, Jan 19, 2018 at 12:51:52PM -0500, Robert P. J. Day wrote:\n> that's all the info i was given, but it *seems* clear that the build\n> process itself was making changes to one or more tracked files.\n> \n>   technically, i guess one can design a build system to do pretty\n> much anything, but is it fair to say that this is a really poor design\n> decision? admittedly, this isn't specifically a git question, but i'm\n> open to opinions on something that strikes me as a bad idea.\n\nI agree that in general it's a bad idea.  I can see how it happens,\nthough, which is because two things come into tension:\n\n1) The general desire not to check in generated files into the git\nrepository --- including configure files generated by autoconf,\nMakefiles generated by automake, libtool files, etc.\n\n2) Wanting not to give users trying to build from source a non-hostile\nexperience.  Unfortunately autoconf/automake/libtool systems are\nnotorious for not having a stable interface, such that if you have the\nwrong or outdated version of the tools, the results of generating the\nconfigure, Makefile, etc., using a different version than what the\ndeveloper used.... well, your results may vary.\n\nWhat I do is use \"Maintainer mode\" which means that the generated\nfiles are *not* automatically rebuilt by the build system unless you\nconfigure with --enable-maintainer-mode, and then I *do* check in the\ngenerated files into git.  That way I can run with\n--enable-maintainer-mode, and check in updates to Makefile, configure,\netc., as necessary when the input files change, but that way, end\nusers don't have to worry getting ambushed by version skew caused by\nusing an old (or unexpectedly newer) version of the\nautoconf/autoconf/libtool tools.\n\nHeck, I even have had config.guess/config.sub change on me in\nincompatible ways(*), so I ship my own version and don't enable a blind\nupdate of those files from the upstream FSF sources --- mainly because\nI don't trust them to preserve a stable interface.  Better that I\nmanually pull them into the repo, and test them before I do a public\nrelease.\n\n\t\t\t\t\t- Ted\n\n(*) Although to be fair it's been years since I've been screwed in\nthis fashion.  But once bitten, twice shy....\n"},{"id":"336920","messageId":"robbat2-20180119T183103-843967451Z@orbis-terrarum.net","threadId":"47645","inReplyTo":"alpine.LFD.2.21.1801191247250.10222@localhost.localdomain","subject":"Re: should any build system legitimately change any tracked files?","fromName":"Robin H. Johnson","fromEmail":"robbat2@gentoo.org","sentAt":"2018-01-19T18:45:20Z","receivedAt":"2018-01-19T18:45:33Z","isPatch":false,"sender":{"key":"robbat2@gentoo.org","avatar":"https://avatars.githubusercontent.com/u/373898?v=4"},"body":"On Fri, Jan 19, 2018 at 12:51:52PM -0500, Robert P. J. Day wrote:\n> \n>   just finished teaching a couple git courses and, after class, a\n> student came up and described a rather weird problem -- in short:\n> \n>   1) before build, \"git diff\" shows nothing\n>   2) do the standard build\n>   3) suddenly, \"git diff\" shows some changes\n> \n> that's all the info i was given, but it *seems* clear that the build\n> process itself was making changes to one or more tracked files.\n> \n>   technically, i guess one can design a build system to do pretty\n> much anything, but is it fair to say that this is a really poor design\n> decision? admittedly, this isn't specifically a git question, but i'm\n> open to opinions on something that strikes me as a bad idea.\nI have seen what you describe, but it had a good cause:\n1. The source repo contained some intermediate generated source, \n   eg foo.x -> foo.c -> foo.o\n2. The output of the tool that did foo.a -> foo.c differed due to some\n   factor on the system (different version, different config in /etc etc).\n3. The initial checkout caused the mtime of foo.c to be just older\n   newer than foo.x, so the build system decided to regen foo.c.\n4. (optional) The makefile had conditional rules to skip the regen if the tool was\n   not present.\n\nUntil the tool output changed, even if the file was regenerated, it was\nidentical, so it didn't show up in diff.\n\nWhat are the possible mistakes here?\n- The intermediate source possibly should not be committed [depending on\n  the tool, this isn't always an option]\n- The build system scripts (makefile etc) contains a mistake.\n- Some final (non-intermediate/non-source) file was committed.\n\nI've seen similar patterns for GNU Bison, autoconf, and lots of other\ntools. \n\n-- \nRobin Hugh Johnson\nGentoo Linux: Dev, Infra Lead, Foundation Treasurer\nE-Mail   : robbat2@gentoo.org\nGnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85\nGnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136\n"}]}