Building LLVM crashes on low-memory machines

[prateekchawla168]

Building LLVM crashes on low-memory machines when using a parallel build. The only diagnostic available from the logs is :

g++: fatal error: Killed signal terminated program cc1plus.

This is roughly ~45 mins into a build on a 16-core machine with 32 GB RAM.

[Thyre]

I like the idea proposed in #3971. However, this will require us moving from CMakeMake to CMakeNinja, which may have implications on other assumptions we make in the EasyBlock.

LLVM can take lots of resources, and being able to reduce the memory footprint of link steps can be valuable, especially when building the static libraries. Not everyone is building on an HPC machine with lots of memory available, and even building with 8 or more threads can be enough to run OOM with 32GB of memory.

[prateekchawla168]

I'm willing to send a PR to move the LLVM easyblock from CMakeMake to CMakeNinja. Would that be acceptable?

[Thyre]

We'd need to make sure that this doesn't have any side-effect on currently supported LLVM EasyConfigs, but that's manageable. What do you think @Crivella, @Flamefire?

I remember that we had some issues which upstream LLVM claimed to probably be solved if we switch to Ninja. So that might also be a reason to try this out...

[Flamefire]

Using Ninja instead of Make sounds very good.
Only issue: It requires an update of all easyconfigs to include Ninja as a build dependency. That might be painful but we have that already in other places like numpy IIRC where they switched the build system for their software.

Not sure if we can solve this more generically. E.g. have different software specific easyblocks for one software with version metadata where either-or is selected.

[Crivella]

I'm willing to send a PR to move the LLVM easyblock from CMakeMake to CMakeNinja. Would that be acceptable?

I am not against it, would just be surprised if it works by just switching Make to Ninja without breaking anything

E.g. have different software specific easyblocks for one software with version metadata where either-or is selected.

You mean something similar to the Quantum Espresso EB?
I think that could be generalized as long as the sub EBs have the same set (or atleast a compatible one of extra_options)

[Flamefire]

You mean something similar to the Quantum Espresso EB?
I think that could be generalized as long as the sub EBs have the same set (or atleast a compatible one of extra_options)

That's an interesting approach... But seems to work.
So yes something like that. They don't even need compatible options as depending on the version either one is used, so no conflicts there. IIRC options used in the EC are only checked when creating the easyblock, aren't they?

For LLVM specifically we can maybe simply "create" a class at runtime out of the same class where we just change the base class. Then we can decide on a version where we switch and update only those easyconfigs.

[Crivella]

They are checked when reading the EC in order to get the version.
You have to be careful if you are changing defaults from one EB to another or if you have mandatory parameters in one EB but not the other

EDIT: actually i might've gotten around the defaults overriding problem in

easybuild-easyblocks/easybuild/easyblocks/q/quantumespresso.py

Lines 86 to 88 in e88a534

	# Required to avoid CMakeMake default extra_opts to override the ConfigMake ones
	new_ec = EasyConfig(ec.path, extra_options=eb.extra_options())
	# Disable log file for nested EasyBlock

, might be less tricky than i remember