I would say no, since the configure would not really work well with
amber10 I'm guessing... though since maybe amber10 uses config_amber.h
(and ambertools uses config.h), it won't make such a big deal... I'd
still say it'd be safer to separate the two, though others may know
how (in)compatible at1.3 is with amber10. If there is no required
hard-coded reference to AMBEROME in the executables themselves, I
don't think it's crucial that all executables be in the same folder,
as long as both folders are in the PATH. Also, if it does prove to be
an issue, there will probably be a good bit of discussion on the
mailing list.
My opinion is that ultimately we should aim for independence of AT and
AMBER such that they can be upgraded independently (especially since
at upgrades will be coming out more frequently than amber upgrades).
Especially since one is open source and the other is not, it seems
logical to allow amber10 users to keep amber10 and upgrade tools
without needing also upgrade amber. One way of potentially solving
this is to have separate folders and separate environment variables
AMBERHOME and AMBERTOOLSHOME (or something to that extent)... but this
is probably a topic for future discussion.
All the best,
Jason
On Wed, Dec 23, 2009 at 1:21 PM, Sally Pias <sallypias.gmail.com> wrote:
> One very small concern: I downloaded AmberTools 1.3 from the Amber
> website and unpacked it, in order to install AmberTools and Amber 10
> together. AmberTools unpacked into a directory labeled amber11/ .
> Does this need to be adjusted until Amber 11 is actually released?
>
> Regards,
> Sally Pias
> --
> Simmerling Research Group, Stony Brook University
> sallypias.gmail.com
>
> On Wed, Dec 23, 2009 at 12:29 AM, Mengjuei Hsieh <mengjueh.uci.edu> wrote:
>> On Tue, Dec 22, 2009 at 10:30:24PM -0500, David A. Case wrote:
>>> On Tue, Dec 22, 2009, Mengjuei Hsieh wrote:
>>> > One problem I just found out in the tarball is that the FLIBSF in
>>> > src/configure is not correct, it should not contain carpack and
>>> > f2c. Here is a patch to the script and also corresponding change to PBSA
>>> > Makefile.
>>> I am lost: why do you think that FLIBSF doesn't need carpack and f2c? Won't
>>> such a change break sander?
>>> We could rework the various library variables in configure, but that should be
>>> done with care. Since carpack and f2c have to get compiled anyway, I don't
>>> see any real loss in having the loader look at (and ignore) them. Am I
>>> missing something here?
>>
>> I thought the difference between FLIBSF and FLIBS should be the usage of
>> C compiler in FLIBS, but apparently I misunderstood the meaning of it.
>>
>> The only potential issue of this is on the occasion of static linked
>> binaries, so yes it indeed doesn't matter much systematically.
>>
>> Best,
>> --
>> Mengjuei Hsieh, Luo Research Group, Molecular Biology & Biochemistry,
>> University of California Irvine.
>>
>> _______________________________________________
>> 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
>
--
---------------------------------------
Jason M. Swails
Quantum Theory Project,
University of Florida
Ph.D. Graduate Student
352-392-4032
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Wed Dec 23 2009 - 16:30:03 PST
