Hi,
On Thu, 9 Oct 2008, David A. Case wrote:
> On Thu, Oct 09, 2008, Roberto Gomperts wrote:
> >
> > Immediately I encounter several problems, starting with how configure_at
> > generates config.h for irix_cc. For example it defines a "ranlib"
> > function not present in irix.
>
> will fix.
I didnt see a fix; so i added one while cleaning up the irix_cc
section. see configure_at revision 1.67
> > Also no fortran compiler is set.
>
> Probably correct as is: the *only* fortran compilers known to work with mopac
> are g77 and gfortran. If neither are present, the install process should just
> skip compiling mopac. Of course, it is possible that SGI's f90 would also
> work, but I don't know that anyone has tested this.
sgi's f77 has worked - at least mopac was built with f77 in dock 6.2
circa 3-2008 and the dock amber score tests passed which use antechamber
to generate charges.
also past versions of amber built mopac on sgi's;
maybe we dont know whether they 'worked'.
> I keep hoping we can deep-six the mopac code soon...Ross??
I added f77 to irix_cc, but because of the mopac contortions
f77 won't get put into config.h, sigh.
I'd rather help with the qm replacement than rewrite configure_at's
handling of fortran since several people have monkeyed with that already.
> > reduce/Makefile uses a CURRENT_DIR variable that has not been set
i arbitrarily defined CURRENT_DIR
since its used only in echo commands.
> > reduce/reduce_src/Makefile has a bug in defining the OBJLIST:
> > OBJLIST = GraphToHoldScores.o reduce.o CTab.o ElementInfo.o StdResH.o
> > ResBlk.o AtomConn.o \
> > AtomPositions.o DotSph.o Mover.o RotMethyl.o RotDonor.o \
> > FlipMemo.o CliqueList.o AtomDescr.o PDBrec.o MoveableNode.o \
> >
> >
> > CXX = $(CPLUSPLUS)
I dont see the bug; the cut n paste above is not what is in the current
revision 10.2
date: 2008/06/26 02:55:12; author: vbabin; state: Exp; lines: +6 -3
since the current revision has hybrid_36_c.o
Please clarify this bug?
> Will fix, but this and other parts of AmberTools (sleap & gleap) really
> require the GNU versions of make and lex. I'm wondering if it is just not
> simpler to say: "you have to install GNU tools to use this software": does
> the number of IRIX and Solaris users justify the efforts to keep our code
> compatiable with "legacy" Unix?
I dont see that these are "make" version issues.
I got the same behavior with these makes:
GNU Make version 3.79.1, by Richard Stallman and Roland McGrath.
make SunOS 5.7 Last change: 11 Aug 1998
> > So a continuation "\" in the last line.
>
> will fix.
I dont see a fix or a bug; please clarify this bug.
> > I fix this and then I get into actual compilation errors.
> >
> > For example:
> > ./nab -c dna3_to_allatom.nab
> > cc -c -woff 1116,1167,1174,1552 -Wl,-dont_warn_unused -DSYSV
> > -DBINTRAJ -o dump.o dump.c
> > cc -c -woff 1116,1167,1174,1552 -Wl,-dont_warn_unused -DSYSV
> > -O0 -DSYSV -DBINTRAJ -Dlex embed.c
> > cc-1028 cc: ERROR File = lex.dg_options.c, Line = 45
> > The expression used must have a constant value.
> >
> > FILE *dgoin = {stdin}, *dgoout = {nabout};
>
> This is actually odd, since we do test nab installation on an (old?) sgi_mips
> IRIX machine. But it could be that I had installed flex (=GNU lex) on that
> machine, which I no longer have access to.
This bug has been reported:
http://bugzilla.ambermd.org/show_bug.cgi?id=93
> > I suppose that I am a bit surprised by all of this as I have not
> > problems building for x86_64 and ia64 with the Intel compilers.
>
> These are not compiler issues, I think. Rather, it's the old Unix versions of
> make and lex that are only partially compatible with flex that are at fault
> here.
It may be premature since Ive asked for two bug clarifications
(and aside from bug 93), but all the bugs above seem to be programmer errors
not directly OS, make, lex or compiler issues.
configure_at has been the victim of myopic work, inconsistency with
configure (now configure_amber) from the start, and inadequate testing.
Take note:
the configure scripts benefit from a level of care and disipline and
thorough testing above and beyond your normally high standards.
In addition, detailed comments in the scripts and the logs are useful.
Scott
Received on Fri Dec 05 2008 - 11:18:32 PST
