"make install" equivalent for bigdft

[ltalirz]

Hi @adegomme ,

as part of an effort to make our ansible roles more "standard", I'm transforming the roles for codes such that they install the codes directly to the /usr/local/ prefix by default (so that all users of the VM/server can use them).

By convention, this is usually achieved by a ./configure --prefix=/usr/local, followed by make; make install.
I notice that bigdft does not seem to have such a mechanism (?)

As I see that you add some paths to the LD_LIBRARY_PATH, can I ask:

• which are the executables that would need to be copied to /usr/local/bin/ ?
• which are the libraries that would need to be copied to /usr/local/lib/ ?

[adegomme]

Hi,
it's true that we don't provide at the moment an easy (one line) way to add a single option to the build when you are using an rcfile. The only option is to add the command to the rcfile used to configure the build.
In our case, this would mean creating a local buildrc file in the build folder (if it exists, it will be used by default for the build), and filling it with the content of the provided rcfile we were using, adding our prefix.

So replacing the "../Installer.py build -y -a babel -f ../rcfiles/ubuntu_MPI.rc -v" line by

echo 'prefix="/usr/local"' > buildrc
cat ../rcfiles/ubuntu_MPI.rc >> buildrc
../Installer.py build -y -a babel -v

and everything would be installed to /usr/local. I don't know if this can be done in one line in the yaml or if we need to add several sections.

It's true than bigdft build generates and installs a lot of files, so this might bloat a bit /usr/local folder if all codes are put there. Another option then would be to build in the old folder and just move bin/bigdft executable, as long as the whole lib folder to /usr/local/bin(lib). This would prevent some usages, but most of the time bigdft executable is the one used.

Best regards,

[ltalirz]

thanks for the hint - it works!

It's true than bigdft build generates and installs a lot of files, so this might bloat a bit /usr/local folder

I agree. Perhaps the next release of bigdft could be a bit more selective in the executables it installs?

Another request from my side would be to clean up the jh_build directory that is currently created in the prefix:

vagrant@qmobile:/usr/local$ ls -ltr
total 44
drwxr-xr-x  2 root root  4096 Aug  5 20:30 src
drwxr-xr-x  2 root root  4096 Aug  5 20:30 sbin
drwxr-xr-x  2 root root  4096 Aug  5 20:30 games
drwxr-xr-x  2 root root  4096 Aug  5 20:30 etc
lrwxrwxrwx  1 root root     9 Oct 20 08:31 man -> share/man
drwxr-xr-x 12 root root  4096 Dec 15 20:37 share
drwxr-xr-x  8 root root  4096 Dec 15 20:42 lib
drwxr-xr-x  4 root root 12288 Dec 15 20:42 include
drwxr-xr-x  2 root root  4096 Dec 15 20:42 bin
drwxr-xr-x  3 root root  4096 Dec 15 20:42 _jhbuild

[ltalirz]

I wanted to try and include bigdft but after battling with the build script for 1.9.0 I'm going to give up for now.

It seems the Installer.py makes assumptions about __file__ being defined, which it isn't when calling it the way we do in Quantum Mobile. I'm pushing the latest version of the ansible script - would be great if you could give the build a try in a local instance of quantum mobile.

[adegomme]

Putting back the timeout avoidance travis_wait seems to be working for the travis side, at least..

I've had some issues with my quantum mobile setup, so I was unable to regenerate everything with ansible yet .. but logging into the virtual machine and compiling 1.9.0 there went through without issue (with vagrant user, I'm wondering if it's not trying to build it with another user ?)...
I had to make sure ansible was not trying to compile the older version, as it kept pretending that the download phase was not changed... while it only had 1.8.3.

[ltalirz]

Putting back the timeout avoidance travis_wait seems to be working for the travis side, at least..

So sorry about this - I won't touch this anymore.
What is again the reason why this is needed here (but not in any other ansible role I know)?
I'll add a corresponding comment to the .travis.yml

logging into the virtual machine and compiling 1.9.0 there went through without issue (with vagrant user, I'm wondering if it's not trying to build it with another user ?)...

Ok, very strange. The latest version of the role does build it for the vagrant user.

I'll do it again on the latest version of QM I just released and will post the exact error message here (if there is one)

[adegomme]

The issue with travis is just that the build step itself takes more than 10 minutes and triggers a timeout on their ci system, as there is no output in the meantime, so they provide this mechanism to avoid it. Apparently bigdft takes the longest to compile on this setup, other codes are ~ twice faster to compile.

[ltalirz]

I can't reproduce the issue I faced on QM - with my new version, the role installs just fine (just needed to fix the LD_LIBRARY_PATH).
I think we can consider this fixed.