Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

It is unbuildable on FreeBSD. Any chance to switch to cmake or meson? #29

Closed
yurivict opened this issue Mar 26, 2018 · 5 comments
Closed

Comments

@yurivict
Copy link
Contributor

GNU makefiles are extremely convoluted, and it can't be built.

Are you able to change to cmake or meson, which are known to be much easier and more scalable build systems compared to gmake?

@jeffhammond
Copy link
Collaborator

Please report actual problems. This sort of issue is unhelpful.

Whatever your issues are with FreeBSD, they are solvable within the existing build system. Please create a detailed issue and we will investigate. It will be relatively difficult to install a FreeBSD VM on the machines I currently have, but I'll try to figure something out if necessary.

Now for some higher-level comments...

The NWChem build system is designed to support a wide range of platforms, including exotic ones where certain tools are not available. While it is not transparent to new developers, it is well-understood by experienced developers and servers our purposes. In a moment of frustration, I tried to rewrite it from scratch (still in GNU make, but with a cleaner design), but realized that this would introduce a huge number of regressions and waste the time of every other developer of the project.

Changing to a different build system is extremely costly in developer time and is unlikely to cause any real benefit. I have seen CMake used for many years by HPC application developers. It is an unmitigated disaster. Meson is a non-starter because it is written in Python3. We are not going to assume Python3 is available on every machine where NWChem is installed.

@yurivict
Copy link
Contributor Author

I have seen CMake used for many years by HPC application developers. It is an unmitigated disaster.

cmake projects normally build on new platforms with almost no problems, while gmake-based projects often do not. Just like nwchem. So IMO it's quite the opposite, based on seeing hundreds of projects of both kinds.

@jeffhammond
Copy link
Collaborator

@yurivict I wrote that comment as someone who has maintained CMake build system projects for more than five years on multiple supercomputers.

As you have failed to provide any information about the problems you observe on FreeBSD, I have no confidence in your assessment about build system quality. For all I know, the reason NWChem isn't building is because of user error or a broken toolchain.

@yurivict
Copy link
Contributor Author

As you have failed to provide any information about the problems you observe on FreeBSD, I have no confidence in your assessment about build system quality. For all I know, the reason NWChem isn't building is because of user error or a broken toolchain.

Same here. As somebody who has seen hundreds of cmake projects, and who has created ports for dozens of them, I can tell you with certainty that cmake-based projects build much easier once CMakeFile.txt files are right. And I have seen many large projects switching from gmake to cmake or meson, for example Urbit operating function (https://github.com/urbit/urbit) or Faust audio processor (https://github.com/grame-cncm/faust). So I have no confidence in soundness of your judgement when you say that gmake is easier.

Anyway, I just need it to build on FreeBSD, and I opened a separate bug report for it, #30 .

@jeffhammond
Copy link
Collaborator

GNU make does exactly what the developers make it do. Any failures in GNU make build systems are failures of the developers, not GNU make itself. In contrast, CMake itself can break builds. Please google cmake infinite loop as but one example where CMake itself is or has been broken.

sb17v pushed a commit to sb17v/nwchem that referenced this issue Oct 8, 2024
no-op implementation, which is what GA appears to be using right now.
there is no documentation of this so i will be implemented using the
ComEx source as the spec, whenever we bother to do that.

This resolves pmodels/armci-mpi#28

Signed-off-by: Hammond, Jeff R <jeff.r.hammond@intel.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants