Closed coldfix closed 10 years ago
dddf1d4 seems to break the build on the test servers. There are at least two solutions:
--madxdir
for the setup process (which I find cleaner)git revert dddf1d4
Which do you prefer?
I'd like to merge this as well, do you have any preferences, whether to strip dddf1d4 or not?
About dddf1d4. It looks cleaner with this change, but I think I remember that the reason for doing it in the current way was to get the rpath handled correctly when compiling. Let me just check that a bit more thoroughly first.
Yes, the rpath won't be detected on the testing servers with this change, so one would need to use the --madxdir
argument there (which I think is more explicit, simple).
Edit:
By any chance, do you know the correct runtime path on the test server? I just added the --madxdir
flag to the ctest script where the build is issued, the argument value is just a guess though. Will that file automatically be executed with the new version or does it reside unversioned in some place on your server? (Sorry, I'm still a little confused about the setup..)
Merged with master: having both 'PyYAML' and 'numpy' as install dependencies and compiling 'numpy' beforehand, leads to a failure on python3 (see travis).. I believe this is due to another bug in setuptools, but I am not sure, where exactly this comes from. If trying twice the installation succeeds:
python setup.py install || python setup.py install
So maybe this PR should be put on hold, until there is a cleaner solution.
I've pushed this one to testing now. I think it is better to clean things up, and --madxdir is easy enough to use for those that need rpath handling (I do e.g. on the test servers where madx is installed to /usr/local).
Okay, I just added the || python setup.py install
line to the Travis build instructions. This is just a minor nuisance, when building on python3 from scratch and the workaround is easy enough, so I think, we can leave it for now.
On the abp-ubuntu1310.cern.ch machine, /usr/local doesn't work. Can you check the path there? I made in the latest commit, such that one can pass --madxdir multiple times, so you could just add the directory in the test/run_tests.cmake
file.
Sorry about that. On this server I have madx installed in ~/.local/. I added --madxdir now so it should work again.
Enable to invoke
setup.py
without prior installation of numpy. This makes the requirements.txt file unnecessary which was used in a somewhat confusing manner. In the future the file can be used to to define stable version configurations instead.Also, I have first simplified the MAD-X path discovery and then removed it altogether. If MAD-X is installed system-wide, it should be usable without manually extending the path variables anyway. If it resides in any nonstandard location, I think it's not too hard to use the --madxdir. This greatly simplifies the code in setup.py and I like simple. If you prefer the additional convenience of the old discovery mechanism, we can strip dddf1d4 from this PR.