Git and our Build Systems

[hoijui]

As explained in the other thread, our Scons setup is not well suited for use in a git environment.
see: viewtopic.php?f=12&t=17319

I now found out, that the problem with CMake is even more severe.
The wiki page of CMake contains this statement in its feauture list:

• Detection of file content changes using traditional timestamps

Looking through the whole CMake docu, i did not find anything that indicates a possibility to change this to detect modification based on file contents.

This creates a problem; imminent in the following example:

Code: Select all

git checkout master
[compile spring with CMake in separate build directory]
git checkout someBranch
git checkout master
# the files now have the timestamp: now (time of the above statement)
[compile spring with CMake in separate build directory]
# even though no changes occured, spring is compiled compleetly (from [0%])

So as it is now, both SCons and CMake work really bad with git branching.
The only solution i know about, is to have separate local repositories for each branch.

Next best solution is to make our builddir in SCons configurable. It seems as if SCons does file modification detection based on content (aswell). So that should work then.

[imbaczek]

try ccache. not sure how to plug it into scons; cmake should be easy.

[Tobi]

AFAIK scons uses checksums instead of timestamps (or maybe both), so I'd suspect that does work fine (unless of course some over-used header file is different between the branches..)

Also scons can use a cache directory, that way the builds with same build dir should be a lot faster. Remove the cache every now and then tho, because it keeps growing indefinitely otherwise. (can easily grow into the many gigabytes)

[Auswaschbar]

Quote for truth:

Git sets the current time as the timestamp on every file it modifies, but only those. The other files are left untouched, which means build tools will be able to depend on modification time and rebuild properly. If build rules change, that can cause a failure anyway, but that is a far less common problem than accidentally not rebuilding.

[hoijui]

hmm.. that is not true (or they mean something else then what i do). when i do checkout, all files and dirs do have the timestamp of this moment. I have for example the folder AI in both master and caiinterface, but its timestamp changes on each checkout anyway.

i read a discussion on the git mailing list where someone had the same problem with an other project. i dont know the reason, but the git people say it is the correct behaviour, to have timestamps on NOW at checkout, instead of recreating/keeping the old ones.
but even if it were only the files that differ between branches, it would be bad if we had to recompile them after each branch switch.

i now also tried ccache, thanks!
it helps, but it is not acceptable either. it takes more then a fourth of the time of compiling all of spring.

this renders the cheap branching of git expensive again, and we end up making few branches, instead of branching often. it also renders CMake slower then Scons if we switch branches often. is there nothing we can do against that?
even if we make the SCons builddir configurable, and mainly use Scons, we still had to maintain CMake... hmm ok maybe we often wont change the build system, and only Auswaschbar and me had to maintain CMake ...
aren't there better solutions?

[Tobi]

Note that a directory timestamp is always updated by the operating system if there is any file/directory creation/deletion directly inside that directory (not inside subdirectories). So it wouldn't surprise me if directory timestamps get set to current time too often. Did you check on separate files that definitely didn't change too?

As for build systems, maybe get used to the fact that every single build system ever made on this planet sucks big time
(Some suck a bit more then others ofc )

[bibim]

The only solution i know about, is to have separate local repositories for each branch.

Well, you don't need several full GIT repositories. You just need 1 bare repository and several GIT working trees that will use the objects of the bare repository.

For example, for BuildServ I use following architecture:
- a master GIT bare repository (ex: "git clone --bare git://github.com/spring/spring.git master"), used as a mirror of the Spring remote repository. It only contains GIT objects and references, no working files...
- several shared GIT repositories (ex: "git clone -s master slave"), used as simple working trees. They only contain working files and references, no GIT objects.

So on the server I only have 1 copy of the GIT objects (VCS repository), and several copies of working files for branches, build systems, toolchains...

In my case I can use shared GIT repositories because I don't plan to commit anything from my BuildServ slave repositories. If you plan to delete branch or perform any other operation that deletes GIT objects from these slave repositories, you might want to drop the "-s" option in the "git clone" command: it will still use hardlinks to save space when possible.

[hoijui]

thanks bibim

yeah.. sounds like a good setup for the buildbot, but for working with branches, it would mean one repository per branch. this is possibly the only solution right now, but not elegant, and not how git is meant to be used, as it makes branching expensive again.

i sent a feauture request to the CMake mailing list. hope we get a response there. if not, i will have to use your solution i guess.

i agree, tobi, they suck

well... the problem seems to be that caiinterface and master have nothing in common so far (from gits perspective), so even files and dirs that are theoretically equal are changed. BrianDamage said this will not happen anymore after the first merge of one of the two to the other, which i should do soon anyway.
but the basic problem remains, it will just be less extreme. when switching between branches, i still will have to compile sources in branchX, that did not really change, just because they differ from the same sources in branchY, which i had checked out somewhere in between the two attempts to compile branchX.

[imbaczek]

well... the problem seems to be that caiinterface and master have nothing in common so far (from gits perspective), so even files and dirs that are theoretically equal are changed. BrianDamage said this will not happen anymore after the first merge of one of the two to the other, which i should do soon anyway.

not git's fault. i'm +1 on merging caiinterface in whatever way soon (even as a single big patch, though some split is desirable.)

[Tobi]

Btw couldn't the problem be that between the branches CMakeLists.txt differs and cmake rebuilds everything if this file is changed? (not sure about either )

[Auswaschbar]

If talked with hom, the problem is that merges from svn were importet as real commits, so every file changed when he switches branches.

[hoijui]

yeah, thats true what Auswaschbar wrote.i now did merge master into caiinterface, was more then 2 hours conflict solving.. i got told that in the future, there should be less conflicts when merging things

Tobi... good point!!! well in my case, .. id did nto matter, as all files differed anyway, but ... this coudl be a problem if we have branches with modifyed CMakeLists.txt...
actually i read something about that today, when i was searching the CMake docu. am too tired and dull from the conflict solving now, but it coudl be a problem. if it is a problem, it will show up now after the merge, as my branch has different CMakeLists.txt files then master. will report later or tomorow.

[imbaczek]

if buildscripts differ, there's no telling what needs rebuilding. the only safe option for any tool is to rebuild everything.

[Tobi]

Not necessarily, scons just used a checksum over the various objects defining the build, IIRC. So if you changed just some whitespace in the SConstruct, or you refactored it, it would not need a rebuild.

There is no reason other build systems could not be that smart too.

[imbaczek]

whitespace yes, but e.g. buildoptions, or glob patterns? i don't know how scons checksums files, but if it doesn't include ccflags, it won't work correctly. also, it's late and there's a chance i am babbling ^^

[Tobi]

Yeah of course it does checksum build flags etc. and will rebuild if you change those; point is that as long as build flags etc. stay the same it will not rebuild, no matter how much you modify the buildsystem itself.

[bibim]

yeah.. sounds like a good setup for the buildbot, but for working with branches, it would mean one repository per branch.

Actually it's not one repository by branch, it's more one working directory by branch. GIT calls them "shared repositories", but "alternate working directories" fits more imho (these directories don't contain VCS repository data strictly speaking, they use the VCS data of the main repository).

this is possibly the only solution right now, but not elegant, and not how git is meant to be used, as it makes branching expensive again.

What do you mean exactly by "expensive" ?
On the contrary, this architecture is used quite often in GIT world when simultaneus work on multiple branches is required on the same system, and when building time is critical.
Actually there is even a "git-new-workdir" script shipped with GIT (in debian it is in /usr/share/doc/git-core/contrib/workdir), that will do quite the same as shared repositories except that it uses symbolic links. That way, even GIT configuration, refs, remotes etc. are shared with the main repository, so you can't call these directories "repository" at all anymore. They are just alternate working directories of the same VCS repository.

I suggest you to take a look at the answer of Linus Torvalds himself to your original question.

[hoijui]

thank you bibim
i now setup things localy with separate workdirs/repos for each branch, creating new branches like this:

Code: Select all

NEW_BRANCH=foo
cd repos
git clone -l -n master ${NEW_BRANCH}
cd ${NEW_BRANCH_NAME}
git checkout -b ${NEW_BRANCH} master

i still think it would be better if CMake supported content based file modification detection, specially when you want to have lots of branches with little changes, not just because of harddisc space, but because of having to use less commands/beeing simpler in general.

i will live with it as it is (still bugging on the CMake mailing list )