How to setup an incremental ROOT building procedure

Do there exist any instructions how to locally setup incremental ROOT builds?

Assume one wants to have ROOT binaries for several branches, e.g. the “master” and the “v6-20-00-patches”, and then assume one wants to update one’s (branch specific) ROOT binaries on a regular basis (e.g. once a day or once a week).

I am looking for a procedure which first “updates” the “<branch/specific/sourcedir>” (using “git”, of course) and then “updates” the corresponding ROOT build.

Please note that it is NOT an option to delete the whole ROOT “<branch/specific/builddir>” directory and start configuring and building it from scratch again.

For my purposes, the “update” does not need to be automatic (i.e. I can “manually” run some script which does it when I want it).

Note: It should be enough to “cd <branch/specific/builddir>” and then run the “update” procedure (because the already built binaries know where the sources are so the “update” procedure should be able to automatically “update” the corresponding “<branch/specific/sourcedir>” first).

Hi Wile_E,

git pull
make -j 32

should be good enough? Am I misunderstanding something?

Cheers, Axel.


git pull
make -j 32

Especially with master branch it is not always works this way.
Due to different changes it may be required to reconfigure (call cmake again) and build from scratch.
Probably, one can add such check in update scripts - if simple pull and make fails - reconfigure all


@Axel You follow the standard “four-steps” procedure:

cd <build/specific/sourcedir> # I need to precisely know which "soucedir"
git pull # NOT for git "tags" NOR for unpacked ".source.tar.gz" files
cd <build/specific/builddir> # that's what I actually want to "update"

I guess I would appreciate a simple “two-steps” fool-proof procedure:

cd <build/specific/builddir>

The “update_me” script should be clever enough to automatically deal with everything:

  1. find which “build/specific/sourcedir” should be used (the one that was used during the initial cmake configuration step, of course),
  2. if “sourcedir” comes from a git “branch”, apply “git pull” there,
  3. if “sourcedir” comes from a git “tag” or from unpacking a “.source.tar.gz” file, do nothing (source code cannot change in these cases),
  4. run “make”,
  5. if “make” fails, reconfigure it (with the same options that were used during the initial cmake configuration step) and run “make” again.

You may wonder why run “make” again if the “sourcedir” was not changed because it comes from some git “tag” or from unpacking a “.source.tar.gz” file.
Well, the standard operating system packages / libraries are updated on a regular basis (at least on well maintained systems). Usually, nothing should be needed (just the new system provided shared library will be loaded at runtime) but sometimes it may be needed to rebuild / relink ROOT’s libraries, especially if static system libraries were used (or some system library’s “#include” files were upgraded). So, ROOT should get the chance to deal with the “upgraded” system libraries, too. Again, rebuilding ROOT from scratch when some system libraries change is NOT an option (unless the clever “update_me” script fails to “make” it in the point “4.” above, of course).

Actually, instead of a separate “update_me” script, maybe ROOT could provide a dedicated “--target update” which goes from point “1.” to “4.”. Something like:
cmake --build . --target update -- -jN
The point “5.” could be excluded here by default … if the rebuilding dies then the user would be responsible for the reconfiguration.

Additionally, if the “update” target discovers in point “2.” that some important cmake configuration files were changed (in the source code), then the user should get an explicit verbose message IN BIG LETTERS that reconfiguration may be necessary (even if point “4” went fine).

One could also add yet another “--target upgrade” which would do the same as “update” but if some important cmake configuration files were changed in the source code in point “2.”, or in case of problems in point “4.”, it would automatically reconfigure it (i.e. include point “5.” when desired, possibly even before point “4.”).

That’s a nice idea - also because we could move some of our continuous integration code into root.git. Alas I think CMake cannot pull itself out of the pond: to re-configure someone would need to call it, and that needs a driver script. But it might help with the basic “git pull”-part. Happy to see a PR opened by anyone (that should probably also cover roottest)!

Well, actually I asked my original question because I hoped you had some magic “update_me” script hidden in some “continuous integration code”.

Anyhow, if a new “--target update” is created (which will cover points “1.” to “4.”), please do not include “roottest” in it. (the default “make” step does not have it either).
You could add yet another cmake target which would include it for the purpose of the “continuous integration” (i.e. points “1.” to “4.” and then automatically “roottest”).

Covering point “5” is not that much important. I think it may be left to the user to perform it manually (but the user should get a warning from the “update” target that reconfiguration may be necessary, as described in my previous post).

It does, actually: if -Dtesting=On and roottest is found, also roottest targets are built. And in that case, with your suggested new target, roottest should also be updated.

O.K. If that is what you mean then I see no problem here … if “-Dtesting=ON” was present during the initial cmake configuration step then it will stay this way, so nothing new is needed when running step “4.” (but if it was NOT initially present then it should NOT be switched “ON” when running the “update”).

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.