From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Nguyen Thai Ngoc Duy" Subject: Re: Separating generated files? (Re: Mercurial -> git) Date: Wed, 15 Oct 2008 21:54:26 +0700 Message-ID: References: <48F5D86B.6040501@pflanze.mine.nu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Gambit List To: "Christian Jaeger" , "Git Mailing List" X-From: gambit-list-bounces@iro.umontreal.ca Wed Oct 15 16:56:14 2008 Return-path: Envelope-to: glsg-gambit-list@m.gmane.org Received: from mercure.iro.umontreal.ca ([132.204.24.67]) by lo.gmane.org with esmtp (Exim 4.50) id 1Kq7n6-0004DX-A2 for glsg-gambit-list@m.gmane.org; Wed, 15 Oct 2008 16:56:00 +0200 Received: from mercure.iro.umontreal.ca (localhost.iro.umontreal.ca [127.0.0.1]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id 99C202CFD81; Wed, 15 Oct 2008 10:54:50 -0400 (EDT) X-Original-To: gambit-list@iro.umontreal.ca Delivered-To: gambit-list@iro.umontreal.ca Received: from perlin.iro.umontreal.ca (perlin.iro.umontreal.ca [132.204.24.51]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id 40A422CFD81 for ; Wed, 15 Oct 2008 10:54:48 -0400 (EDT) Received: from rv-out-0708.google.com (rv-out-0708.google.com [209.85.198.246]) by perlin.iro.umontreal.ca (Postfix) with ESMTP id AFC83148233 for ; Wed, 15 Oct 2008 10:54:27 -0400 (EDT) Received: by rv-out-0708.google.com with SMTP id k29so2668009rvb.8 for ; Wed, 15 Oct 2008 07:54:26 -0700 (PDT) Received: by 10.141.74.18 with SMTP id b18mr679104rvl.159.1224082466530; Wed, 15 Oct 2008 07:54:26 -0700 (PDT) Received: by 10.141.154.18 with HTTP; Wed, 15 Oct 2008 07:54:26 -0700 (PDT) In-Reply-To: <48F5D86B.6040501@pflanze.mine.nu> Content-Disposition: inline X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-2.533, requis 5, autolearn=not spam, BAYES_00 -2.60, RCVD_BY_IP 0.07, SPF_HELO_PASS -0.00) X-DIRO-MailScanner-From: pclouds@gmail.com X-Spam-Status: No X-BeenThere: gambit-list@iro.umontreal.ca X-Mailman-Version: 2.1.8 Precedence: list List-Id: Discussion of topics related to the use of the Gambit Scheme system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: gambit-list-bounces@iro.umontreal.ca Errors-To: gambit-list-bounces@iro.umontreal.ca Archived-At: Hi Christian, The idea of using two separate repositories for source and generated source is interesting. I would like to bring this to git mailing list, they may provide insightul comments for your idea or even other approaches. Background for Git people: gambit-c was previously stored in mercurial. The main source is in gambit-c (a Scheme implementation or a Lisp dialect). *.scm files generate *.c, which will be compiled by gcc as usual. Both *.scm and generated *.c are now stored in mercurial. Gambit-C maintainers have recently decided to move to Git. On 10/15/08, Christian Jaeger wrote: > 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. -- Duy