[MOAB-dev] MOAB build system

Wed Nov 17 14:48:24 CST 2021

Hello,

I will vote for cmake.

Regards,
Lukasz

Sent from my iPhone

> On 17 Nov 2021, at 20:00, Vijay S. Mahadevan <vijay.m at gmail.com> wrote:
> 
> 
>> 
>> 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>