Hi all,
after some testings, I go head merging my change for --prefix option to
master branch.
Those commits should not affect your regular workflow (hopefully) but if
any, please let me know (or even better if make a new commit to fix :D).
Usage example: You can try different compilers by
mkdir $HOME/try_amber_prefix
cd amber17
./configure --prefix $HOME/try_amber_prefix gnu
source amber.sh
make install
After the regular install, all installed files will be in
$HOME/try_amber_prefix.
Of course, to run programs in try_amber_prefix folder, you still need to
source $HOME/try_amber_prefix/amber.sh
Expected failures if running the tests for "--prefix" option:
FEW.pl: I don't know Perl well to make change, so just let it be.
pymsmt: It's using some library in its source folder at run time. I think
Pengfei is working on this.
Hai
On Thu, Feb 2, 2017 at 1:05 PM, Hai Nguyen <nhai.qn.gmail.com> wrote:
> thanks. I will look at the Python stuff.
>
> Should expect not able to run some (most?) tests (even if copying
> $AMBERHOME/test and AmberTools/test to $PREFIX)
> since some of the tests point to the source folder.
>
> cheers.
> Hai
>
>
> On Thu, Feb 2, 2017 at 1:02 PM, Daniel Roe <daniel.r.roe.gmail.com> wrote:
>
>> PS - The 'prefix' install was 328MB, compared to 2.5 GB for a full
>> Amber 16 install. Very nice.
>>
>> On Thu, Feb 2, 2017 at 1:00 PM, Daniel Roe <daniel.r.roe.gmail.com>
>> wrote:
>> > Got a chance to try this today. I haven't tested thoroughly but it
>> > seems to work well. Nice work Hai!
>> >
>> > I hit a brief hiccup during my initial attempt with python stuff:
>> > ```
>> > Checking .pth file support in
>> > /u/droe/Amber/TEMP/prefix/lib/python2.7/site-packages/
>> > /mnt/local/droe/anaconda2/bin/python -E -c pass
>> > TEST FAILED: /u/droe/Amber/TEMP/prefix/lib/python2.7/site-packages/
>> > does NOT support .pth files
>> > error: bad install directory or PYTHONPATH
>> > ```
>> > It went on to describe the problem and potential solutions which was
>> > really nice, but the real issue was I had forgotten to source amber.sh
>> > - that fixed the problem. So maybe that could be the first thing you
>> > suggest for potential solutions?
>> >
>> > -Dan
>> >
>> >
>> > On Wed, Jan 25, 2017 at 3:48 PM, Hai Nguyen <nhai.qn.gmail.com> wrote:
>> >> Oops, no "="
>> >>
>> >> ./configure --prefix $HOME/try_another_folder gnu
>> >>
>> >> On Wed, Jan 25, 2017 at 3:31 PM Hai Nguyen <nhai.qn.gmail.com> wrote:
>> >>
>> >>> > If I happen to get free time before
>> >>> now and the code freeze maybe I'll take another crack at making this
>> >>> happen.
>> >>>
>> >>> .Dan: I have working code in amber_prefix_Hai branch. Feel free to
>> try and
>> >>> update that.
>> >>>
>> >>> ./configure --prefix=$HOME/try_another_folder gnu
>> >>>
>> >>> Hai
>> >>>
>> >>> On Thu, Dec 22, 2016 at 9:44 AM, Daniel Roe <daniel.r.roe.gmail.com>
>> >>> wrote:
>> >>>
>> >>> On Wed, Dec 21, 2016 at 10:04 PM, David Case
>> >>> <dacase.scarletmail.rutgers.edu> wrote:
>> >>> >
>> >>> > On Wed, Dec 21, 2016, Dan Roe wrote:
>> >>> >
>> >>> >>
>> >>> >> But I think it is important that these tests happen at 'configure'
>> >>> >> time, and it doesn't seem to me to be that difficult....
>> >>> >
>> >>> > It may indeed be do-able, but it is not just a matter of seeing if
>> >>> "import
>> >>> > numpy" throws an error. The configure script would have to compile
>> >>> python
>> >>> > extensions in the same way the real code will (which is actually
>> several
>> >>> > ways), and make sure they all work. And since only developers will
>> >>> decline
>> >>> > the miniconda download, and since they can find out by trial and
>> error if
>> >>> > their system python works, writing and maintaining this
>> functionality
>> >>> seems
>> >>> > like a lot of work for only a small payback.
>> >>>
>> >>> I think that some users (maybe installs at HPC sites etc) may also
>> >>> want to decline the miniconda download, but it does seem like python
>> >>> detection is problematic. As long as the '--with-python' flag works I
>> >>> think it's fine anyway. It would be nice to have configure be able to
>> >>> test the python ecosystem but if it's too much work then I'll just put
>> >>> it on my wishlist.
>> >>>
>> >>> > For those who want to play with this, configure2 alreay *has* a
>> >>> > check_compatible_python() function. We commented out the call to
>> this
>> >>> > function (about line 935) since it was not reliable enough: having
>> >>> > configure say a python is OK when it is not is quite annoying and
>> >>> confusing.
>> >>>
>> >>> Agreed - that's worse from a user standpoint for certain.
>> >>>
>> >>> > Knowing I'm repeating myself: we *really* don't want users
>> installing
>> >>> > packages into their existing python just to install Amber. There
>> is too
>> >>> > much danger of creating incompatibilities with other things that
>> require
>> >>> > python: that is, we increase the danger that installing Amber breaks
>> >>> > something else on the user's computer. [numpy, in particular,
>> exists in
>> >>> > several incompatible releases; it is quite easy for program A to
>> require
>> >>> > version 1.9 and program B to require version 1.10. We can't solve
>> that
>> >>> > problem, but should not make it worse, either.]
>> >>>
>> >>> This is one of the gotchas of living in the python universe. Advanced
>> >>> users can just use the '--with-python' flag. "Normal" users can have a
>> >>> built-in miniconda. We just have to make it clear during configure
>> >>> time exactly why miniconda is a good idea instead of the vague "well,
>> >>> maybe stuff won't work" message of the past.
>> >>>
>> >>> >> I'll have to test '--with-python', but if it works there is not
>> much
>> >>> >> of a downside that I can see other than that Amber installation is
>> now
>> >>> >> the "python keystone", so I'd better not ever move it or I will
>> break
>> >>> >> every Amber install based on it (and it's another configure flag
>> that
>> >>> >> has to be specified each time).
>> >>>
>> >>> I was being a bit facetious about having to specify an extra flag :-)
>> >>> - that stuff doesn't come through in email sometimes. I think the
>> >>> '--with-python' flag is the correct solution.
>> >>>
>> >>> >> > [Next thing we know, people are going to want to be able to
>> specify a
>> >>> build
>> >>> >> > directory, separate from the sources.....]
>> >>> >>
>> >>> >> I still want this :-). For separate installs the size can really
>> add
>> >>> >> up, more because the Amber 16 source tree weighs in at 2.3 GB - the
>> >>> >> miniconda install adds 635 MB to that (sizable but not egregious).
>> >>> >
>> >>> > Has anyone tried to just make a shadow directory (using "cp -as" or
>> >>> lndir),
>> >>> > with links to a clean amber tree, then build in the shadow
>> directory?
>> >>>
>> >>> Unfortunately, this can't work for multiple parallel library/CUDA
>> >>> version builds (maybe I'm not understanding what you mean).
>> >>>
>> >>> > Realistically, I'd recommend bigger disks. You can get 500 Gb
>> external
>> >>> > SSD drives with USB-3 or USB-C interconnects that are quite fast
>> and will
>> >>> > allow you create all the Amber images you are ever likely to
>> need....
>> >>>
>> >>> Just because disk space is cheap doesn't mean we should be wasteful. I
>> >>> would like to do with Amber what I can do with every other linux
>> >>> source code package: have one giant source directory that I can point
>> >>> to an install directory with '--prefix', and then that install
>> >>> directory contains only what I need to run that version of Amber.
>> >>> AMBERHOME can point to the common source, but PATH and LD_LIBRARY_PATH
>> >>> point to the install directory. If I happen to get free time before
>> >>> now and the code freeze maybe I'll take another crack at making this
>> >>> happen.
>> >>>
>> >>> -Dan
>> >>>
>> >>> --
>> >>> -------------------------
>> >>> Daniel R. Roe
>> >>> Laboratory of Computational Biology
>> >>> National Institutes of Health, NHLBI
>> >>> 5635 Fishers Ln, Rm T900
>> >>> Rockville MD, 20852
>> >>> https://www.lobos.nih.gov/lcb
>> >>>
>> >>> _______________________________________________
>> >>> AMBER-Developers mailing list
>> >>> AMBER-Developers.ambermd.org
>> >>> http://lists.ambermd.org/mailman/listinfo/amber-developers
>> >>>
>> >>>
>> >>>
>> >> _______________________________________________
>> >> AMBER-Developers mailing list
>> >> AMBER-Developers.ambermd.org
>> >> http://lists.ambermd.org/mailman/listinfo/amber-developers
>> >
>> >
>> >
>> > --
>> > -------------------------
>> > Daniel R. Roe
>> > Laboratory of Computational Biology
>> > National Institutes of Health, NHLBI
>> > 5635 Fishers Ln, Rm T900
>> > Rockville MD, 20852
>> > https://www.lobos.nih.gov/lcb
>>
>>
>>
>> --
>> -------------------------
>> Daniel R. Roe
>> Laboratory of Computational Biology
>> National Institutes of Health, NHLBI
>> 5635 Fishers Ln, Rm T900
>> Rockville MD, 20852
>> https://www.lobos.nih.gov/lcb
>>
>> _______________________________________________
>> AMBER-Developers mailing list
>> AMBER-Developers.ambermd.org
>> http://lists.ambermd.org/mailman/listinfo/amber-developers
>>
>
>
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Sat Feb 04 2017 - 17:30:03 PST
