Enable local installation without root access

Question

Enable local installation without root access

jowr opened this issue 10 years ago · comments

Edit the makefile to handle bot, a system-wide and a local installation. Useful for users working on machines without root access.

Deleted user · Answer 1 · Fri Apr 25 2014 20:31:45 GMT+0800 (China Standard Time)

BTW, it's not necessary to follow exactly @nkampy's procedure in order to have the 64 bits modification to work ; notably, you can run trunk.m directly from the repo directory, without copying to the install folder, which avoids the chmod and to run matlab script in /usr ;-)

Jorrit Wronski · Answer 2 · Fri Apr 25 2014 20:49:23 GMT+0800 (China Standard Time)

The makefile can be used without root privileges now. However, I do not understand the procedure involving thunk.m.

Could you, @nkampy and @speredenn, please agree on how to handle this and clarify the instructions? BTW, adding an export of LD_LIBRARY_PATH to a bash profile is not recommended... See also: http://www.cc.dtu.dk/?page_id=304

Deleted user · Answer 3 · Fri Apr 25 2014 22:01:33 GMT+0800 (China Standard Time)

yeah @jowr, I write a set of instructions the way they work for me and keep you tuned for the root access first, then I will give a try to the no root access instructions.

Deleted user · Answer 4 · Sat Apr 26 2014 00:38:12 GMT+0800 (China Standard Time)

The procedure, with root access, on a GNU/Linux 64 bits computer, with code at commit b847a93, is:

as root, at the root of the repository: make, then make install (and before make clean if needed, of course).
as a normal user, copy in the matlab folder the refpropm.m and rp_proto64.m files from NIST. Check in refpropm.m that the library path is correct (/opt/refprop/ in current version), and that you have the line prototype = @() rp_proto64(BasePath); below the line dllName = 'librefprop.so'; (normally it is not there, you'll need to add it), in the switch computer structure (line 189).
as a normal user, from the matlab folder, run ./fixfiles.sh.
in MATLAB, as a normal user, in the matlab, run run('thunk.m'); ; the problem here to automate the process with the Makefile is to access the matlab binary from the command line ; on GNU/Linux it is often not in the user's PATH and in OSX, you need to get it from within the .app package, which is ugly.
as a normal user, in the matlab folder, mv rp_proto64.m rp_proto64.m.thunk, then cp rp_proto64.m.du rp_proto64.m
as a normal user, replace the string REFPRP64_thunk_pcwin64 in the file rp_proto64.m by the string librefprop_thunk_glnxa64, taken from file rp_proto64.m.thunk. You can sed it, I think. It's line 10.
as root, cp refpropm.m librefprop_thunk_glnxa64.so rp_proto64.m /opt/refprop/
as a normal user, in matlab, 'addpath('/opt/refprop')'; then it should work.

This is what should do the Makefile, I guess :-/ ; it would be great then to test that on OSX and GNU/Linux, from scratch. At least this exact procedure works on my own computer, step by step.

Jorrit Wronski · Answer 5 · Sun Apr 27 2014 19:26:17 GMT+0800 (China Standard Time)

The new makefile and scripts from d135d0e should improve the user experience. However, testing is needed. Especially for OSX and non-root users.

Jorrit Wronski · Answer 6 · Sun Apr 27 2014 20:16:32 GMT+0800 (China Standard Time)

It works on 32bit Linux. @speredenn, could you test it on 64bit Linux? ...and @ibell, maybe you find the time to try it on your Mac...

Deleted user · Answer 7 · Sun Apr 27 2014 22:23:32 GMT+0800 (China Standard Time)

The way I have tested your commit 93a0350:

clone the repository
copy fluids and mixtures folders from REFPROP in the files folder
copy the fortran code from REFPROP in the fortran folder
download in the matlab folder the 3 refpropm files from the NIST FAQ
as root, in a terminal, make, then make install
as root, make matlab, and I followed the instructions, as a normal user outside the command line (modification of the files, etc...)
Tested in MATLAB R2013a 64 bits, on a GNU/Debian experimental 64 bits. Works fine.

I have one or two minor improvements and corrections to propose; I commit then directly in your master branch, as they are trivial changes. Thanks for the hard work! Integration could be better, but that's already fairly good :-).

Deleted user · Answer 8 · Sun Apr 27 2014 22:33:28 GMT+0800 (China Standard Time)

Done with the trivial modifications, pushed in your master branch (63155aa and 8165eba).

Deleted user · Answer 9 · Sun Apr 27 2014 22:54:19 GMT+0800 (China Standard Time)

@nkampy: could you test the above procedure with the jowr/master HEAD commit on your MacOS 64 bits setup and confirm that it works too? :-)

Jorrit Wronski · Answer 10 · Mon Apr 28 2014 15:01:00 GMT+0800 (China Standard Time)

Thanks for the testing and the contribution. Just one comment: I included the download of the m files in the makefile. You should not have to download anything manually...

Deleted user · Answer 11 · Mon Apr 28 2014 16:02:24 GMT+0800 (China Standard Time)

Oh right, I had skipped reading this part in the Makefile ; sorry. Great that the Makefile downloads the files directly!

nkampy · Answer 12 · Tue Apr 29 2014 05:02:54 GMT+0800 (China Standard Time)

Ok guys, I've hit a wall in trying to install the new version on a mac. When installing as the root for make and sudo make install then if I run sudo make matlab I can't modify refpropm.m in matlab or in Xcode.

Second, from a clean download, make and sudo make install then trying make matlab things bugger up at step two as the files aren't copies over to the documents/matlab folder.

Third, in the directions when running the fix files.sh script it may help to avoid confusion to be clear that the matlab folder in question is not the documents/matlab but the download location ..../librefprop.so-master/matlab location.

Jorrit Wronski · Answer 13 · Tue Apr 29 2014 13:14:13 GMT+0800 (China Standard Time)

OK, I separated file handling and installation and updated the instructions to point to the correct matlab folder. Please try the following:

Run sudo make uninstall clean to remove the fortran files and sudo rm matlab/*.m.org to clean the matlab files.
Run make and then sudo make install to install the shared library.
Run make matlab to download files and edit them as written in the terminal.
Run sudo make matlab-install to copy the matlab file to /opt/refprop.

I hope that works for you. I have not been able to test it...

Jorrit Wronski · Answer 14 · Tue Apr 29 2014 14:56:55 GMT+0800 (China Standard Time)

There are still some rough edges, but I think I got quite far. You might have to copy the dylib manually after you ran make matlab...

nkampy · Answer 15 · Wed Apr 30 2014 03:41:28 GMT+0800 (China Standard Time)

Jowr, Your doing great! You guys have pulled off some pretty impressive stuff.
Here is a run down of additional steps that I had to take to get your method to work on my mac (sudo make matlab):
before step 1

sudo chown USERNAME:wheel refpropm.m
before step 2
sudo chown USERNAME:wheel rp_proto64.m
after
copy the thunk.dylib to the refprop install folder opt/refprop

At this point the test code runs just fine from the librefprop.so-master/matlab folder

I would recommend the script automatically move refpropm.m, rp_proto64.m and librefprop_thunk_maci64.dylib to opt/refprop. Then inform the end user to add the path opt/refprop to the matlab path.

Then any matlab script can call the ref prop method from anywhere on the computer.

Let me know what you guys think about the email I sent to NIST with the recommended changes. I'm hoping this makes things easy to install in the future and secondly make the methods available for less advanced users who can't get mex working with matlab.

Ian Bell · Answer 16 · Wed Apr 30 2014 03:46:08 GMT+0800 (China Standard Time)

Just an FYI, I'm going to be working at NIST starting in January. Can you
forward me the email you sent to NIST to ian.h.bell .at. gmail.com ?

On Tue, Apr 29, 2014 at 9:41 PM, nkampy notifications@github.com wrote:

Jowr, Your doing great! You guys have pulled off some pretty impressive
stuff.
Here is a run down of additional steps that I had to take to get your
method to work on my mac (sudo make matlab):
before step 1

sudo chown USERNAME:wheel refpropm.m before step 2

sudo chown USERNAME:wheel rp_proto64.m after

copy the thunk.dylib to the refprop install folder opt/refprop

At this point the test code runs just fine from the
librefprop.so-master/matlab folder

I would recommend the script automatically move refpropm.m, rp_proto64.m
and librefprop_thunk_maci64.dylib to opt/refprop. Then inform the end user
to add the path opt/refprop to the matlab path.

Then any matlab script can call the ref prop method from anywhere on the
computer.

Let me know what you guys think about the email I sent to NIST with the
recommended changes. I'm hoping this makes things easy to install in the
future and secondly make the methods available for less advanced users who
can't get mex working with matlab.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/15#issuecomment-41722447
.

nkampy · Answer 17 · Wed Apr 30 2014 04:00:49 GMT+0800 (China Standard Time)

ibell, Congrats! what group are you going to? The long and short of the email was 3 suggested changes to how refprop is integrated into matlab. 1- expanding the switch case by computer return type in matlab. 2 - removing the BasePath input argument from the prototype file which as far as I can tell is an aftermarket modification that complicates the porting process. both of these will simplify the install process. 3 - propose a uniform naming convention for the dynamically shared library functions to enable a single make file for all platforms including windows, mac and linux without having to rename things to lower case for unix systems. (IE for librefprop.so to match the original refprop names) This would increase code portability across platforms.

nkampy · Answer 18 · Wed Apr 30 2014 05:12:38 GMT+0800 (China Standard Time)

@jowr dug through the new parts of the make file and realized I wasn't following your directions to run make matlab-install after. Found an issue and repaired it. Just not sure how to code up the chown fix for the make matlab problem.

Jorrit Wronski · Answer 19 · Wed Apr 30 2014 14:14:33 GMT+0800 (China Standard Time)

@nkampy, you should not need to chown the files. The script downloads them as normal user, then you edit them as normal user and eventually matlab-install copies them as root user and fixes permissions so everyone on the system can read/execute them. Are you sure they have to be chowned?

Jorrit Wronski · Answer 20 · Wed Apr 30 2014 14:51:46 GMT+0800 (China Standard Time)

I just tested it and it works without any "chowning". Please report any issues. Installation should be similar on all Macs if there is a difference between @nkampy's machine and mine, we need to find out what is going on.

Jorrit Wronski · Answer 21 · Tue May 06 2014 00:40:57 GMT+0800 (China Standard Time)

Can we consider this done? @nkampy does it work for you without changing file ownership?

nkampy · Answer 22 · Tue May 06 2014 00:52:35 GMT+0800 (China Standard Time)

My last attempt required using chown. Not sure why. I used the sudo command. Is it possible my sudo does something different than your sudo command?

On May 5, 2014, at 11:40 AM, Jorrit Wronski notifications@github.com wrote:

Can we consider this done? @nkampy does it work for you without changing file ownership?

—
Reply to this email directly or view it on GitHub.

Jorrit Wronski · Answer 23 · Tue May 06 2014 03:25:04 GMT+0800 (China Standard Time)

No. I do not think so. But it is important to start from a clean directory. If you ran a command with sudo that should not be run as root, you might end up with files having the wrong permissions... That is why I recommend the cleaning procedure earlier in this thread:

Run sudo make uninstall clean to remove the fortran files and sudo rm matlab/*.m.org to clean the matlab files.
Run make and then sudo make install to install the shared library.
Run make matlab to download files and edit them as written in the terminal.
Run sudo make matlab-install to copy the matlab file to /opt/refprop.

However, the safest way is to clone the whole project again to anew directory.

nkampy · Answer 24 · Tue May 06 2014 04:52:09 GMT+0800 (China Standard Time)

Starting from a clean install, It works. It would be nice to verify with another tho as it seemed to be glitchy, but I couldn't quite figure out why. Also, I would change the cp commands to mv for refpropm.m and .dylib as multiple copies of the proto64 file can cause problems.

Ok, now that this stage is pretty well rounded out. We could try the next level of simplicity for installing the matlab interface. It is possible to bypass the mex compilation required portions of the process by providing the end user with the thunk.dylib, rp_proto files that go with it based on what system they have. These files are meant to be cross computer compatible for the same platform. IE any red hat linux 64 bit machine can use the same exact files as another without compiling the code over again. (Binaries) This might put the code into the hands of people who cant get the mex functionality in matlab working.

On May 5, 2014, at 2:25 PM, Jorrit Wronski notifications@github.com wrote:

No. I do not think so. But it is important to start from a clean directory. If you ran a command with sudo that should not be run as root, you might end up with files having the wrong permissions... That is why I recommend the cleaning procedure earlier in this thread:

Run sudo make uninstall clean to remove the fortran files and sudo rm matlab/*.m.org to clean the matlab files.
Run make and then sudo make install to install the shared library.
Run make matlab to download files and edit them as written in the terminal.
Run sudo make matlab-install to copy the matlab file to /opt/refprop.
However, the safest way is to clone the whole project again to anew directory.

—
Reply to this email directly or view it on GitHub.

Deleted user · Answer 25 · Tue May 06 2014 13:38:00 GMT+0800 (China Standard Time)

@nkampy I disagree ; I've experienced that, depending on your GNU/Linux or OSX version + depending on your MATLAB version, the mex file was not working and needed to be recompiled for the specific computer, over time (and I've needed this procedure many many times). So I disagree that it could be a good idea to provide something which has been compiled thanks to the shitty MATLAB ways ;-). I would recommend to keep the things being done by the users, when they get the code. Moreover, it is a bad idea to keep binaries in a git repository while you could just compile them from the code ;-).

Jorrit Wronski · Answer 26 · Tue May 06 2014 14:30:16 GMT+0800 (China Standard Time)

I'll change the cp to mv.

Thank you all for the contributions! I hope that we can get Eric to change the .m files in the NIST FAQ, this will make the installation much easier. I agree that the compilation can be left to the users. However, we can discuss other options to make even less complicated. For now, I will release the next version since I consider support of 64bit Linux and Mac a big improvement! Thanks again for sharing your experience, both of you.