Hi Franky,
On 06/10/15 11:16, Backeljauw Franky wrote:
Hello all,
We are trying to build spglib-1.7.4-intel-2015b.eb using “eb
—try-software-version=1.7.3 spglib-1.7.3-intel-2015b.eb”. The only
change is the version number, but when trying to build it fails with:
main.easyblock WARNING build failed (first 300 chars): *Can't
change to real build directory
/dev/shm/spglib/1.7.4/intel-2015b/spglib-1.7.4/spglib-1.7.4*
This problem seems to be caused by filetools after the unpacking of
the sources.
If we use version spglib-1.7.3, we get:
...
== 2015-10-06 10:39:15,294 *main.filetools DEBUG Last dir list
['spglib-1.7.3', '._spglib-1.7.3']*
== 2015-10-06 10:39:15,294 *main.filetools DEBUG Possible new dir
/dev/shm/spglib/1.7.3/intel-2015b found*
...
But with spglib-1.7.4, we get:
*...*
== 2015-10-06 10:43:04,559 *main.filetools DEBUG Possible new dir
/dev/shm/spglib/1.7.4/intel-2015b/spglib-1.7.4 found
...
*
The only noticable difference between the two tar-files is that
spglib-1.7.3.tar.gz also contains the file "./._spglib-1.7.3” which
results in different behavior of "main.filetools DEBUG Possible new
dir”. If I remove this file from the tarfile of spglib-1.7.3.tar.gz, I
also get the same issue when trying to build it with EasyBuild.
Any ideas how to recover from this issue?
After unpacking sources, EasyBuild checks if there's a single directory
found. If so, it uses that as the 'start directory', and moves into it
after unpacking (which is what you're seeing with 1.7.4).
If there are multiple directories (including hidden ones), EB doesn't
pick a start directory, and stays in the build directory (i.e.
intel-2015b, in this case).
You can tell EB what the start directory is however, using the
'start_dir' easyconfig parameter.
This is specified for spglib v1.7.3, as follows:
start_dir = '%(name)s-%(version)s'
But, since the auto-guessing of the start directory works for 1.7.4,
this is no longer needed (and wrong even).
So, just remove this line from the easyconfig file for 1.7.4 (and create
a pull request for it ;)).
This is one example where using --try-software-version doesn't work,
which is why it's called 'try'.
Things may change for newer software versions...
I hope this clarifies what's going on.
regards,
Kenneth
