thanks. I will investigate.
Hai
On Mon, Feb 6, 2017 at 1:16 AM, Scott Brozell <sbrozell.rci.rutgers.edu>
wrote:
> Hi,
>
> In a fresh repo of the master:
> ./configure -mkl --skip-python intel
> make
> ...
> make[2]: Leaving directory `/tmp/amber/AmberTools/src/nfe-umbrella-slice'
> (if [ "yes" = "no" ]; then \
> make python_serial ;\
> fi;\
> )
> (python conda-recipe/scripts/patch_amberhome/copy_and_post_process_bin.py
> /tmp/amber/bin /tmp/amber/bi
> n)
> Traceback (most recent call last):
> File "conda-recipe/scripts/patch_amberhome/copy_and_post_process_bin.py",
> line 228, in <module>
> main()
> File "conda-recipe/scripts/patch_amberhome/copy_and_post_process_bin.py",
> line 224, in main
> script_template=script_template)
> File "conda-recipe/scripts/patch_amberhome/copy_and_post_process_bin.py",
> line 158, in copy_to_targe
> t_folder
> print('patching {}'.format(final_exe_path))
> ValueError: zero length field name in format
> make[1]: *** [serial] Error 1
> make[1]: Leaving directory `/tmp/amber/AmberTools/src'
> make: *** [install] Error 2
>
> On Sat, Feb 04, 2017 at 08:24:01PM -0500, Hai Nguyen wrote:
> > 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.
>
> _______________________________________________
> 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 Sun Feb 05 2017 - 23:00:02 PST
