Re: [AMBER-Developers] Changes to the CMake build system

From: Hai Nguyen <>
Date: Tue, 10 Oct 2017 20:48:28 -0400

On Wed, Oct 4, 2017 at 9:52 AM, David A Case <> wrote:

> On Mon, Oct 02, 2017, Jamie Smith wrote:
> >
> > I am merging some significant changes into master today....
> Hi Jamie (and other developers):
> Thanks for your work on this. A few points:
> 1. The wiki page says that users need to switch to the cmake branch, but
> all your recent stuff has been committed to master, which seems to work
> fine
> for me. Should we expect the master branch to be mostly working? That is
> what is needed to get real testing done. (I see that the "packaging" stuff
> is still just in the cmake branch, but am unclear about a "regular" build.)

I think "regular" build is ok now. There are a serious of edge cases here but Jamie will
resolve it ( I think ). I am also setting nightly build for cmake on travis

> 2. For everyone: please try this stuff out: I'd really like to switch
> over soon, and have this well-tested enough to be a part of next
> Spring's release. At some point, either Jamie or I can re-write the
> $AMBERHOME/configure script to simply call cmake (rather than the
> current call to $AMBERHOME/AmberTools/src/configure2). That will make
> installation look more like what everyone is used to.

I agree with others about not deprecating non-cmake for AT18. It's too
Even if we deprecate, we should give user a nice message about that.

> > ---- Build Source Directories
> > The CMake build system does not work properly if the Makefile build
> > system has been used to build the Amber source directory. The module
> > files in the source directory override the ones that CMake is building,
> > and cause problems. Make sure to run make clean before building with
> > CMake.
> 3. Just to be clear here: is it expected that one could use cmake to build
> inside a (clean) source directory? Having the out-of-source-tree build
> option
> is great for developers, but might be confusing for some users. For people
> that just want to build once, and rarely change the source code, is
> building
> in the source tree a reasonable option?

I am +1 for build outside source code. (just personal favor).

> 4. (Minor): which MacOS vesions disable DYLD_LIBRARY_PATH? And let me know
> if I can help with getting mpinab to work.

Apple always try to disable it so we won't rely on that. We should use
absolute path or rpath for thoses.
(I think Jamie does that for cmake too).

AMBER-Developers mailing list
Received on Tue Oct 10 2017 - 18:00:02 PDT
Custom Search