I believe the "allocatable array inside a structure" problem is my fault. I
am not sure if it is F2003-specific or not. It works for me with gFortran
4.4.5 and ifort 12.0 (on both Linux and Windows). Anyway, I will see if
there is any possible way to re-write this part.
Taisung
> -----Original Message-----
> From: David A. Case [mailto:case.biomaps.rutgers.edu]
> Sent: Thursday, June 09, 2011 4:32 AM
> To: AMBER Developers Mailing List
> Subject: Re: [AMBER-Developers] Compilation of AMBER Tools
>
> On Wed, Jun 08, 2011, Ross Walker wrote:
> >
> > We used pointers I believe. Since the allocatable argument inside a
> > structure is F2003 if I remember correctly. We could just switch back to
> > that to avoid issues.
>
> Ah...I forgot that part about being inside a struct. If we are sure that
> this
> is an F2003 extension, we could ask people not to make use of it.
>
> >
> > mm_options.l(31): error: identifier "hcp_h" is undefined
> > { ECHO; hcp_h = atof( &mmotext[6] ); }
> > ^
>
> I'm pretty sure this arises because there was an lex.mm_options.c file
left
> over from a previous compilation. This was an effort to accommodate
people
> who don't have flex installed: the code would fall back to using
> lex.mm_options.c if it is present, but this doesn't work if it is out of
> date.
>
> I'm not entirely happy with this explanation, since the "clean" target in
> AmberTools/src/sff should remove the old version. So: can you check date
> stamps to see what could be happening? Compare the time-stamp of
> lex.mm_options.c with that of mm_options.l Note that the current git
> version
> of mm_options.l (and hence lex.mm_options.c) does *not* have either hcp_h
> or cutres, so somehow you are getting a file from an earlier version.
>
> We could force the Makefile to re-make the .c file, effectively forcing
> users
> to install flex. Maybe that is the best option. But knowing the exact
> sequence of commands that leads to this would also help. I suspect that
> this
> affects developers who tend to make and re-make amber in the same
directory;
> but it still should get fixed.
>
> ...dac
>
>
> _______________________________________________
> 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 Thu Jun 09 2011 - 05:30:02 PDT
