change build system to something other than hand-maintained makefiles

[nicolasbock]

Hi,

I was wondering whether you had entertained the idea to switch to a more standard build system, such as e.g. autotools or CMake? Standardizing on the build system helps packagers and users so they don't have to learn yet another Makefile (please don't take this as a criticism of your Makefile :smile: It is actually very easy to read).

Thanks

[olifre]

Hi,

my personal 2 cents... since I also wondered whether this might be a good idea when packaging Charliecloud :wink:. I would personally not use autotools for new projects (I also see some Gentoo devs not wanting to take care of new autotools-based packages). Young developers learning autotools are slowly becoming less and less, so also to attract young developers, it's likely not the best choice.

Concerning CMake, I like it personally, but of course it adds another dependency: You need to have CMake available to build charliecloud, you might even need a specific minimum version. While that's not a problem at all for distro packaging, it might reduce portability for the UDSS usecase when users compile charliecloud themselves on clusters where it's not installed yet. The main issue with CMake is often that there are by now so many versions out there that it's become hard to write both backwards-compatbile and, at the same time, state-of-the-art CMake scripts.

On more modern choices (meson, SCons etc.) I can't talk from experience, but they usually require bootstrapping of some binary, or e.g. meson being installed, which is rare even on modern OS's today.

So my personal feeling would be: If the move to a more standard build system is made, I'd still go with CMake, however, I'm not sure it will be a huge gain - especially, since the current makefile nicely integrates with distro packaging as far as I can see. Just have a look at how short the EAPI 7 ebuild for Gentoo is: https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-cluster/charliecloud/charliecloud-0.2.4.ebuild It would not be much shorter (if at all) with CMake. Of course, the CMake-script may be much shorter than the current Makefile which would be a gain.

Maybe CMake would be nice to have in addition, but I'm note sure development resources are there to take care of it in addition to the classic make.

That's just my personal feeling, let's see what our BDFL thinks :smile: .

Cheers, Oliver

[nicolasbock]

Those are good points @olifre, thanks! I agree with you that in the end any build system introduces a dependency and that it boils down to choosing one that is easily available in all use cases you care about. And installing something on an HPC system as a regular user is certainly a case were I would expect almost nothing useful to be installed out of the box :wink:.

The last time I had access to LANL's HPC systems though I think CMake was available as a module, but I might not remember this correctly. @reidpr please correct me if I am wrong. But I don't know what the situation is on other HPC systems and CMake might be a show stopper on some.

I don't think maintaining two separate build systems is very useful because of the added difficulty of keeping them both working.

Since opening this issue I spent more time reading through the Makefile and it's actually much better than I thought initially (sorry I have this reflex against Makefile build system because I have seen too many that are plainly ridiculous :smile:). I am still curious to hear @reidpr's opinion, but personally I would be happy also if the project stayed with a plain Makefile :smile:.

[nicolasbock]

And :+1: for the Gento ebuild!

[olifre]

@nicolasbock Thanks! Yes, I can also confirm CMake is available on both our HPC (or rather, HTC) clusters at a German University - in our case, it's distributed by CERN via CVMFS (a cool filesystem, but sadly they don't put modules on it, but developed their own spaghetti of scripts :cry: ). Users can choose amongst many versions this way. That should be true for almost all sites involved in High Energy Physics. But still, one cannot be sure how the situation is on other clusters.

I don't think maintaining two separate build systems is very useful because of the added difficulty of keeping them both working

Agreed - ROOT did that for about a year mostly efficiently, maintaining CMake while missing pieces were still added and Makefile in parallel, but finally, the classic Makefile (which was becoming more and more of a mess, and made packaging really hard) broke very often, and is now finally almost unmaintained. mpv also dropped its inherited Makefile from mplayer quite a while ago after trying to maintain both (WAF and Makefile) in parallel for about a year.

Since opening this issue I spent more time reading through the Makefile and it's actually much better than I thought initially (sorry I have this reflex against Makefile build system because I have seen too many that are plainly ridiculous smile).

I can fully understand, I have the very same reflex, and it's usually correct :wink: . Charliecloud indeed has an exceptionally good and readable Makefile, that's very uncommon :+1:.

[mej]

I agree with you that in the end any build system introduces a dependency and that it boils down to choosing one that is easily available in all use cases you care about. And installing something on an HPC system as a regular user is certainly a case were I would expect almost nothing useful to be installed out of the box.

It's also important to keep in mind that we build Charliecloud packages for straight SLES12/RHEL7 as RPMs; for this, I use a container-based build system that leverages prescriptively built, minimal container images to perform each build in a controlled, reproducible manner. That means each spec file needs to specify all the build requirements, which in turn means that all the build requirements need to be yum install-able directly, either from upstream SLES/RHEL/CentOS. (I take a bit of license on that with respect to the documentation, since the required sphinx bits aren't in the upstream repo but can be installed via pip.)

The last time I had access to LANL's HPC systems though I think CMake was available as a module, but I might not remember this correctly. @reidpr please correct me if I am wrong. But I don't know what the situation is on other HPC systems and CMake might be a show stopper on some.

That's correct, but as I mentioned above, we don't generally build our packages (at least not the RPMs) directly on the clusters but rather in a well-controlled container "farm." Thus, depending on modules on the clusters is a no-no. :-)

[reidpr]

So my take is that because Charliecloud does no configuration and the build is pretty simple, the hand-maintained Makefile is OK.

I am open to argument that we should use something different, consistent with the principle of minimizing dependencies and complexity. However, I don't see a strong argument for something different above.

I'd add that even as BDFL, I feel that I have very limited flexibility to get ahead of informed public opinion. That is, I'm not going to put my foot down on a live debate unless it seems there's an impasse or something like that.

[reidpr]

This discussion seems to be over with at least a rough consensus in favor of the status quo, so I'm closing the issue. If I've misread things, please re-open.