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
Received on Thu Jun 09 2011 - 02:00:02 PDT
