Hi Curt, The best way to handle this is definitely using out-of-source builds. In your git repo, just create build-<branch> dir's, and build from there. For autotools, just run ../configure && make && make install, or ccmake .. && make && make install if you want to use cmake. I do this all the time, works fine.
Stefan 2011/1/24 Curtis Olson <curtol...@gmail.com>: > I have another git question: > James has created v2.2.0 release branches on the git server. > I would like to keep up-to-date builds of both versions here. > > If I switch branches in the source tree, git switches the files under > version control but doesn't touch any files it doesn't know about. (Leaving > all the build objects from the other tree.) > With CVS/SVN, my approach was just to check out separate trees, one for each > branch, have two completely independent builds, and then I could "cvs > udpate" and then "make" in either tree to update my build of either branch. > As far as I understand git, you can't have two separate/independent branches > active for a repository at one time. If I do a build of the "next" branch, > then switch to the releases/2.2.0 branch, I still inherit all the build > object files from the other branch. So then I have to do a complete make > clean; make for simgear and flightgear each time I want to jump from one > branch to the other ... which could be quite often as the 2.2.0 release > nears. This seems *highly* non-optimal in terms of wasted time and wasted > work ... especially for people who might be bouncing back and forth several > times in quick succession to test/edit/test/edit a bug fix in both branches. > The other approach would be to have two completely separate git > repositories, one that sits with the 2.2.0 branch checked out and one that > sits with the next branch checked out, but that wastes a bunch of disk space > and also seems really non-optimal. > Perhaps another approach would be to do out-of-source builds. I think > automake/conf should support that, although it's been a while since I've > tried it. > What's the best way to handle this sort of work flow in the git world? > Thanks, > Curt. > -- > Curtis Olson: > http://www.atiak.com - http://aem.umn.edu/~uav/ > http://www.flightgear.org - http://www.flightgear.org/blogs/category/curt/ > > ------------------------------------------------------------------------------ > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! > Finally, a world-class log management solution at an even better price-free! > Download using promo code Free_Logger_4_Dev2Dev. Offer expires > February 28th, so secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsight-sfd2d > _______________________________________________ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > ------------------------------------------------------------------------------ Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
