[MOAB-dev] MOAB build system

[Vijay S. Mahadevan]

> 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.

With CMake, we will have to standardize how TPL directories are
specified. If the TPL was installed with CMake, then TPL_ROOT should
point to the ${tpl_prefix}/lib/cmake directory. Otherwise, TPL_DIR
points to ${tpl_prefix} dir. This is sort of the logic I've been using
to make sure the CMake build system works correctly. However, it
definitely may not be the standard and should get cleaned up when we
start working on this.

> 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.

That is weird - though I don't think we currently sync exactly all the
compiler options that are enabled in autotools and CMake. So I agree
that there may be differences in performance in either full debug or
optimized modes. But 10x improvement makes me curious. We should be
able to test this out easily with both when linking to any MOAB
mini-app against autotools and CMake installations. The build system
should technically have no effect on the library performance, as long
as we can control all the options passed to the compiler and linker
underneath.

Vijay

On Wed, Nov 17, 2021 at 2:41 PM Shriwise, Patrick C <pshriwise at anl.gov> wrote:
>
> 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>