[Cmb-users] Superbuild questions

[Ben Boeckel]

On Sat, Sep 24, 2016 at 19:45:18 -0400, David Thompson wrote:
> > 1. When cmb-superbuild is cloned (and submodules updated) does it
> > pull in the current master head versions of cmb and smtk?

No, they are not cloned as part of the superbuild itself; the build will
default to building the master branches though.

> That depends on whether you have set the superbuild to developer mode
> or not. The default is not developer mode, which will fetch CMB and
> SMTK into the superbuild's **build tree** (i.e., not the superbuild
> source). They are currently both pulling the master branches, but that
> is likely to change.

This is by default. There are also `smtk_FROM_GIT` (default to ON) and
`smtk_FROM_SOURCE_DIR` (defaults to OFF and only available if
`smtk_FROM_GIT` is also OFF). If both are OFF, it will try to fetch the
latest release's tarball (which doesn't exist right now). If you are
using git, you can use `smtk_GIT_REPOSITORY` and `smtk_GIT_TAG` (though
these might have upper case names now, that should be changing with
backwards support; use what you see in the editor) to whatever you want.
If you want to use the superbuild with a custom SMTK build, use
`smtk_FROM_SOURCE_DIR` and point it at whatever source tree you want.
This is what you want if you want to test out custom binaries with an
arbitrary SMTK and/or CMB. CMB has the same set of flags with the
obvious name replacements.

The rule of thumb is that if it is outside the superbuild build tree,
it's safe, but underneath it is fair game for the superbuild to do
whatever it wants to those directories.

> 2. Remove the "install" directory of any existing superbuild's build tree.

For safety with this step, also remove `superbuild/*/stamp/*-install` so
that the superbuild knows it needs to reinstall all the projects.

> You should always do #1 when updating the superbuild. #2 is because of
> some recent changes and you should always need to do this, although it
> is a good step to try when hitting build issues.
> 
> > 3. I'm going to be testing model-builder on a workflow being
> > developed, so I expect I'm going to want to be pulling in the latest
> > changes on cmb/smtk.  What I'd like, is to use cmb-superbuild to
> > build and package just the TPLs, which I can stick somewhere, and
> > then build cmb/smtk from their repos, pointing to the TPL
> > installation.  I'm sure this must be one of the workflows, but I
> > don't know how to do it. I noted the DEVELOPER_MODE_{cmb,smtk} cmake
> > variables, which I suspect are relevant somehow.
> 
> Yes, when the DEVELOPER_MODE_xxx variables are set, then only TPL
> libraries are built; you are expected to build CMB and/or SMTK
> elsewhere. Take care when you do this because you must use the same
> TPLs everywhere. On my machine, I will get system versions of boost,
> hdf5, gdal, etc. when I build SMTK without explicitly pointing
> CMakeCache.txt to the superbuild.

Yes, the superbuild build dumps an "smtk-developer-config.cmake" into
its build tree which you use with `cmake -C
.../smtk-developer-config.cmake ...` to make SMTK use it (and again,
obvious name changes for CMB as well). You may need to set the
environment up to use the superbuild's tree (particularly PYTHONPATH
and, on Windows, PATH).

--Ben