[MOAB-dev] MOAB build system

[Shriwise, Patrick C]

Hiya,

Another vote for CMake from me for all the reasons previously stated.

One thing I’ll note is that we got a report from Andrew Davis that there can be a significant difference in performance between a CMake and autotools build. He stated that his group was seeing nearly a 10x improvement in their application when switching to an autotools build (presumably with an equivalent set of options enabled). We may want to investigate further. I’ll reach out to him to see if I can get a script and maybe a miniapp to reproduce this.

Best,

Patrick
________________________________
From: moab-dev <moab-dev-bounces at mcs.anl.gov> on behalf of Paul Wilson <paul.wilson at wisc.edu>
Sent: Wednesday, November 17, 2021 1:19:46 PM
To: vijay.m at gmail.com <vijay.m at gmail.com>; moab-dev at mcs.anl.gov <moab-dev at mcs.anl.gov>
Subject: Re: [MOAB-dev] MOAB build system

Hi all,

I'll add my vote for CMake.  My group has invested some effort in the
CMake support over the last few years and I would intend to continue this.

At the risk of creating scope creep in this thread, this may also be an
important (necessary?) opportunity to consider what assumptions we make
about how/where TPLs are installed and using default macros to find TPLs.

Paul

On 11/17/21 12:58 PM, vijay.m at gmail.com wrote:
> All,
>
> Over the past several release cycles, we have continued to support
> both autotools and CMake based build systems in MOAB. While each of
> these workflows have their pros and cons, I think from a longer term
> maintenance standpoint, we are planning to make a transition to use
> just one of these workflows going forward (from the next major
> release).  If you have preferences in using autotools vs CMake, now
> would be a good time to voice your opinions.
>
> Personally, I think the autotools build system is robust when it
> works, but it is old and clunky since it has parts that are nearly 2
> decades old. Additionally, the recent updates to autotools starting
> from version 2.7.x generate a whole lot of warnings when creating the
> configure file. Eventually, all platforms will upgrade to these newer
> versions of autotools and it is not worth our effort in trying to
> maintain autotools given its legacy. However, one advantage with this
> workflow is that we recently added an option to auto-download and
> install optional TPLs in a sandbox for configuration, making it easier
> for users to get started.
>
> For CMake, I may have some complaints about the quirkiness of the
> build language but it has great documentation and works on all
> platforms with a little tweaking (including Windows!). And we should
> be able to get the auto-download feature working here as well with
> either Superbuild type ideas or our own set of macros. While the
> current CMake build system produces nearly equivalent installs as the
> autotools workflow, there are still some kinks that need to be fixed.
>
> In the end, both workflows will require some effort to clean up. And
> given the better platform support and wider adoption of CMake for more
> HPC codes, I am voting CMake for MOAB.
>
> Thoughts, comments and other suggestions are welcome.
>
> Best.
> Vijay
--
-- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ --
Paul P.H. Wilson (he/him/his)
Grainger Professor of Nuclear Engineering
Chair, Department of Engineering Physics <http://engr.wisc.edu/ep>
o: 608-263-0807, c: 608-469-9615
paul.wilson at wisc.edu
153 Engineering Research Bldg
1500 Engineering Dr, Madison, WI 53706
Zoom Meeting Room: https://uwmadison.zoom.us/j/6082630807
Zoom Phone Access: +1-929-205-6099, Access code: 6082630807

Computational Nuclear Engineering Research Group
<http://cnerg.engr.wisc.edu>