Hello All,
If you don’t know me, I’m Jamie Smith, author of the new CMake build system. I am merging some significant changes into master today, and I thought that you should know about them. They should make developers’ lives a bit easier.
---- Incompatible Build Directories
Some of the changes I’ve made alter the layout of CMake’s build directories significantly, enough to cause all sorts of subtle errors. If you had any build directories configured with cmake buildscripts before today, please delete them and recreate them with the new version. Sorry for the inconvenience, I know it’s a pain.
If you try to build an old build directory, you’ll probably get this error:
> CMake Error at cmake/PackageTypes.cmake:53 (message):
> Invalid PACKAGE_TYPE value "TBZ2". Please set it to one of the following
> supported options for this platform: ARCHIVE <other options>
---- Packaging Changes
First of all, I’ve changed the packaging interface to be a little easier to work with. Previously, when you wanted CMake to build archives, each archive type had its own PACKAGE_TYPE value (ZIP, TBZ2, etc.). Now, all archive-type packages are now built with the “PACKAGE_TYPE=ARCHIVE”, and the ARCHIVE_FORMAT variable controls the type of archive that’s built.
I’ve also made several other fixes to the packaging interface, and written a new guide on the wiki for how to use them: http://ambermd.org/pmwiki/pmwiki.php/Main/CMake-Creating-Packages
---- Parallelization Handling
Historically, with Amber, you’ve only been able to build one “type” (serial/parallel/OpenMP/CUDA) of parallelization at a time. If you wanted access to all of them, you’d have to build Amber four different times, and this is a long and arduous process. Until now, the CMake build system has worked in the same way, building a different version of each program depending on the active configuration. However, I have changed that.
Now, when you turn on MPI (-DMPI=TRUE) in CMake, it will build both serial and MPI Amber at the same time! It will use one build directory, and it will only duplicate specifically the programs that use MPI. When you run make install, you’ll end up with both sander and sander.MPI in your install prefix. It works the same way for OpenMP and CUDA. The upside is that you won’t need to keep multiple build directories to ensure that your changes are compatible with all parallelizations of a program. You can just create one super-build directory (cmake -DMPI=TRUE -DCUDA=TRUE -DOPENMP=TRUE) and build all configurations at once!
---- Install Components
To go along with the new multi-parallelization build, I’ve introduced a way to subdivide the installation of Amber into multiple components. You can now run “make install_mpi” to install only the serial programs of Amber, or “make install_data” to install just the data , and so on for all of the other components. To see the full list of install components, run the following command in your configured build directory: “grep '\. install_*' Makefile”. These components are also used when generating Linux packages: when you run make package, Amber will now generate one package for each component, instead of one package for the entire program. This means that users can install only the parts they want, and leave out tests for example.
Speaking of tests, the CMake build system can now install tests, benchmarks, and examples along with the rest of Amber. Just set the new INSTALL_TESTS option to TRUE. Then, the make install_tests target will become available and part of make install, and test packages will be generated from make package. The tests take up over 2GB, so be careful not to clog up your hard drive!
---- Disabling Tools
The old, hack-y FORCE_DISABLE_TOOLS option has been replaced with a new and improved DISABLE_TOOLS option. The old one didn’t understand dependencies between tools, so it was easy to disable something that other tools needed, and get yourself mired in a swamp of dependencies and CMake errors. Luckily for you, I read through every single build script in all of Amber, and created a long list of inter-tool dependencies for the build system to use. Now, if you put a tool in DISABLE_TOOLS that other things need, dependers on that tool will be disabled too. Here’s a segment from the build report when I passed the -DDISABLE_TOOLS=cpptraj option:
-- NOT Building Tools:
-- cpptraj - Disabled by user
-- pytraj - Its dependency cpptraj is disabled.
Cool, right?
---- Python Defaults Changes
To replicate the behavior of the configure script, USE_MINICONDA new defaults to TRUE. This is to reduce user complaints due to broken Python environments.
---- Warnings Defaults
I have switched the warnings option UNUSED_WARNINGS to be off by default now, since unused variables can be a product of how Amber uses #ifdef’s. UNINITIALIZED_WARNINGS, which enables warnings about use of uninitialized variables, is still on, because those warnings are worth addressing.
---- 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.
---- Adding Source Files
Just a small reminder. Since the CMake build system is now usable and merged into master, please make sure that, when you add source files to your projects, they get added to the CMakeLists.txt files too. 95% of the time, it should be as simple as adding the source file to one of the source lists at the top of CMakeLists.txt. I made sure to mirror the Makefiles’ source lists wherever possible, so it shouldn’t be too difficult. If you’re confused about something, just send me an email and I’ll be happy to help.
That’s pretty much it for this round of changes. Make sure to run git submodule update after merging master, because I had to push updates to most of the submodules to support these changes.
If something is broken, please let me know, and I’ll fix it. Please follow the bug report instructions on the wiki: http://ambermd.org/pmwiki/pmwiki.php/Main/CMake-Reporting-A-Bug If you don’t, then I won’t have enough information to accurately diagnose the problem in many cases.
Oh and if you want to learn more about the CMake build system, or you just need something to help you go to sleep at night, feel free to browse the full CMake documentation at
http://ambermd.org/pmwiki/pmwiki.php/Main/CMake I have now documented just about everything you can do with the build system.
Thanks for reading this whole thing,
Jamie Smith
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Sun Oct 01 2017 - 23:00:02 PDT
