On 02/02/2012 01:28 PM, Mike Frysinger wrote: > On Thursday 02 February 2012 15:10:11 Eric Blake wrote: >> Is there any specific reason that gnulib recommends builddir (generated >> files) before srcdir? > > my gut tends to prefer builddir over srcdir. but that could be due more to > poorly managed packages than a "best practices" setup. in cases where a > header file is shipped as part of the distribution and is *usually* used, but > could possibly be regenerated (and thus show up in the builddir), we'd want > the builddir version over the srcdir one.
My counter-response is that anything that gets generated _and shipped_ as part of the tarball should be 1) invariant (no matter how it gets generated, the generated version won't depend on configure results), and 2) generated into srcdir, rather than builddir. If it is generated but depends on configure, it should _not_ be shipped, and should always live in builddir. Therefore, any project that generates files into builddir but then tries to ship them as part of the tarball is broken, for the very reason that it is now impossible to tell whether you want the just-built one or the version-controlled one as part of your tarball. But if the generated version always goes to srcdir, and is truly independent of configure, then your version control system will let you see when regenerating it changes its contents, and that should be an infrequent occurrence. > >> Consider the ramifications if a file changes >> location. If it goes from generated to in-place (moves from builddir to >> srcdir, because it no longer depends on configure results), then >> favoring builddir first means that in an incremental build where you >> forget to run 'make clean' before updating gnulib, the stale generated >> header will be left over in the build tree and be picked up in >> preference to the new gnulib file. Conversely, if a header goes from >> in-place to generated, it will no longer live in srcdir, but only in >> builddir, so it doesn't matter whether you favor builddir or srcdir. >> Therefore, it seems to me that best practice would be to always favor >> srcdir first, builddir second. > > it isn't uncommon (in my experience) for this to not be as clean as it should > be. consider people who have older gnulib in their pkg's tree, and then they > update their gnulib checkout (which is located elsewhere), and then run > gnulib-tool in their pkg to update things. if a header went from non- > generated to generated, the older version isn't cleaned out automatically. > in > general, gnulib does not seem to be that good at cleaning up its old stuff. I'm pretty sure that gnulib-tool tries to remove files that used to be controlled but are now generated, thanks to the gl_FILE_LIST macro stored in m4/gnulib-comp.m4 which gnulib-tool consults during an upgrade sequence. But if that's not the case, we should fix it to work correctly, and guarantee that if a gnulib-provided file moves from provided to generated, then the provided version in srcdir will not stick around as a stale file. > > iirc, i hit this exact bug sometime ago with a project and reported it as a > failing in gnulib, but upon debugging we found that i had a stale header in > my > srcdir that went from non-generated to generated and the -I paths picked up > the old one. i felt bad for wasting the gnulib peep's time (it might have > even been you Eric :P). Are you sure it wasn't the other way around, a file that went from generated to in-tree, where the stale generated version got in the way? > > it's also for this reason that in projects i manage, i try to make sure that > *all* files coming from gnulib live in a dedicated dir. that way my > autogen.sh > can just `rm -rf` it before running gnulib-tool. the one or two files that > gnulib likes to stick in the top-level dir anyways are annoying, but i can > cope with that much better now that i have git. Yes, hacks like that render the question of stale files moot. But without resorting to sledge-hammers, can we come to a consensus on which way things should listed be in a best-practices project? -- Eric Blake ebl...@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
