The latest versions of abinit require ever more recent m4 and autotools infrastructures. There are certainly good reasons to use the latest functionalities etc... but I think we should avoid this as much as possible. Upgrading tool versions on HPC servers and clusters is notoriously difficult and painful, and the sysadmins are especially unhappy as few other codes are as strict about the "recentness" of the tools.
I have corrected, further, in my 6.1.1 branch, the reported versions of autoconf and m4 which were required: they were claimed to be 2.59 and 1.4 respectively, whereas the tests were actually for 2.62 and 1.4.6.
Matthieu
autotools versions
Moderators: fgoudreault, mcote
Forum rules
Please have a look at ~abinit/doc/config/build-config.ac in the source package for detailed and up-to-date information about the configuration of Abinit 8 builds.
For a video explanation on how to build Abinit 7.x for Linux, please go to: http://www.youtube.com/watch?v=DppLQ-KQA68.
IMPORTANT: when an answer solves your problem, please check the little green V-like button on its upper-right corner to accept it.
Please have a look at ~abinit/doc/config/build-config.ac in the source package for detailed and up-to-date information about the configuration of Abinit 8 builds.
For a video explanation on how to build Abinit 7.x for Linux, please go to: http://www.youtube.com/watch?v=DppLQ-KQA68.
IMPORTANT: when an answer solves your problem, please check the little green V-like button on its upper-right corner to accept it.
autotools versions
Matthieu Verstraete
University of Liege, Belgium
University of Liege, Belgium
Re: autotools versions
Hello Matthieu,
I agree that we should take care of not upgrading too quickly the Autotools versions we're using. But, beside that, we usually don't use the autotools themselves on the HPC center. I'm explaining.
The makemake stuff is too be used only on the development platform ; on the HPC machines, we're just compiling (and sometime debugging yes also). Compiling does not require to have the autotools installed. That's the trick. And debugging may not imply to run makemake. If so it means that the ABINIT archive changed and it may be more convenient to develop these changes on our own computer anyway. Finally to installed ABINIT on the HPC machine, I suggest not to use bzr and then makemake, but on the contrary to use a make dist or a make dist-bzip2 on your development computer and scp the tarball to the HPC and directly configure there.
This is how I see and use the Autotools. I think Yann has the same point of view and that's why he keeps up-to-date especially with recent Fortran enhancements. But we may be wrong or don't understand your use case. Please give us the use cases when you need the autotools on the HPC machines. Maybe there are some bugs that make the autotools run themselves when they should not for instance.
I agree that we should take care of not upgrading too quickly the Autotools versions we're using. But, beside that, we usually don't use the autotools themselves on the HPC center. I'm explaining.
The makemake stuff is too be used only on the development platform ; on the HPC machines, we're just compiling (and sometime debugging yes also). Compiling does not require to have the autotools installed. That's the trick. And debugging may not imply to run makemake. If so it means that the ABINIT archive changed and it may be more convenient to develop these changes on our own computer anyway. Finally to installed ABINIT on the HPC machine, I suggest not to use bzr and then makemake, but on the contrary to use a make dist or a make dist-bzip2 on your development computer and scp the tarball to the HPC and directly configure there.
This is how I see and use the Autotools. I think Yann has the same point of view and that's why he keeps up-to-date especially with recent Fortran enhancements. But we may be wrong or don't understand your use case. Please give us the use cases when you need the autotools on the HPC machines. Maybe there are some bugs that make the autotools run themselves when they should not for instance.
Re: autotools versions
Hello Damien,
in principle, you are correct, of course, I shouldn't be doing any makemakeing on the clusters, but in practice that is
1) where the bugs appear and are fixed, and in particular
2) where I want my latest developments to be available.
bzr is supremely convenient in this respect, except that (for other good reasons I know) we do not version the configure script and other generated files. If I need to ship over a full tar.gz and build from scratch each time I modify a few routines, it will be hell. The Pouillon method of installing all your own autotools works ok, but as I don't see the necessity in exploiting all the latest auto-fads, we should avoid it unless it is really necessary or presents a strong advantage.
Matthieu
in principle, you are correct, of course, I shouldn't be doing any makemakeing on the clusters, but in practice that is
1) where the bugs appear and are fixed, and in particular
2) where I want my latest developments to be available.
bzr is supremely convenient in this respect, except that (for other good reasons I know) we do not version the configure script and other generated files. If I need to ship over a full tar.gz and build from scratch each time I modify a few routines, it will be hell. The Pouillon method of installing all your own autotools works ok, but as I don't see the necessity in exploiting all the latest auto-fads, we should avoid it unless it is really necessary or presents a strong advantage.
Matthieu
Matthieu Verstraete
University of Liege, Belgium
University of Liege, Belgium