[gambit-list] Separating generated files? (Re: Mercurial -> git)
Christian Jaeger
christian at pflanze.mine.nu
Wed Oct 15 07:47:55 EDT 2008
I wonder whether it would be a good idea, and good occasion to realize
it, to move source files and generated files into separate repositories
and 'link' those together using the git submodule feature.
Expected advantages:
- no clutter when looking through the history (can possibly be mitigated
by constraining git log, git diff etc. to the non-generated paths only,
although I don't think this is possible (cleanly) with the current
directory structure); the same holds true for using "git format-patch"
(one wouldn't usually want to include the generated files in diffs sent
to the mailing list)
- when merging branches, there will usually be no need to deal with
merge conflicts in the generated files (one would just regenerate them
instead)
- [especially for files being generated not by Gambit itself (for
example "configure"),] the files can be regenerated by differing
[external] software versions without having to deal with those
superfluous changes in the source repository.
By still committing the generated files--to a different
submodule--Gambit can still be updated through Git alone, and the
possible advantage of tracking the generated files to see the effects of
changes in compiler sources can still be had.
Expected disadvantages:
- all generated files need to reside in a separate directory structure;
e.g. the file $BASEDIR/lib/_io.c would have to be at a place like
$BASEDIR/build/lib/_io.c instead, where build/ is the submodule taking
all generated files; since the "configure" file is expected to reside at
the toplevel, I guess this would require that "make update" copies it
from $BASEDIR/build/configure to $BASEDIR/configure (assuming that one
cannot use a symlink because of portability reasons).
- to commit the generated files, a separate step is necessary ("cd
$otherrepo; git commit -a", or maybe easier create a "make
commit_generated" make target?)
- to make this work with the "source" repository residing at the
toplevel, the Git superproject repository (of which the "source" and
"build" repositories are submodules) would need to reside in a
non-standard directory, like $BASEDIR/.gitsuperproject/ instead of the
usual .git/, and using the GIT_DIR environment variable to access it,
although this can probably be handled by make targets (i.e. "make
update" would set GIT_DIR=$BASEDIR/.gitsuperproject when calling "git
submodule update").
- there may be some cases to flesh out; like, should "make update"
really call "git submodule update" (which simply sets the submodules to
the reference given by the superproject, throwing away changes done by
the user in the submodules (they can be recovered from the git reflog,
but may still be a surprise)) or should it run "git pull" in each
submodule instead?
I thought I'd bring this up now because if package maintainers need to
adapt some things anyway, that may be a good time to do it now. (There's
even the possibility to split the converted Mercurial repository into
the source + build parts in retrospect now, which won't be possible
anymore later on (without changing the sha1 sums of the whole Git
history with the associated breakage of existing clones), although that
may not be important.)
I'm willing to help in the effort, although I don't know the build tools
(autoconf and make) and their use in the setup well, so I would probably
be quite a bit lost when doing it alone.
Christian.
More information about the Gambit-list
mailing list