FreeTDS Development Group

[James Cameron <cameron AT stl.dec.com>]

"James K. Lowden" wrote:
> All that said, what exactly do you mean by " the lag in autoconf or
> automake versions"?  If you could spell it out for your somewhat
> dim-witted editor, he'd be ever so much obliged.

/me laughs

Okay, I'll spell it out, in sequence.

You (FreeTDS developers) start with a Makefile.am
You run automake and you get a Makefile.in
You make a configure.in or edit the one you are given
You run autoconf and you get a configure
You ship the files at this point as a release

The user downloads the release
The user runs configure and they get a Makefile

Now, my Tru64 UNIX problem is that my cc behaves differently to gcc. 
Makefile.in has gcc flags in it.  This causes the configure to work, but
the make to fail.

        cc: -Wp,-MD,.deps/ *choke* can't eat those flags, twink! [1]

So I have to work back through the chain above to find which step
created the odd gcc flags.  The answer is automake.  automake seems to
have a presumption that you will use gcc.  So I simply step backwards
and restart from running automake.

The "lag in autoconf or automake versions" should be expanded to cover
aclocal.  Some of these tools don't talk well together if they are not
all the most recent version.  The generated configure script will check
to see if the tools are available and _may_ use them.  If the tools are
installed, but are an incompatible version (usually old, hence "lag"),
then configure will still run them and cause trouble.  I've also had a
situation where a package shipped with an older version of one of the
tools couldn't build on a system which had a more recent version.

I wish I understood them too!

Note: [1] compiler message simulated for enjoyment.

-- 
James Cameron                                      (cameron AT stl.dec.com)

Save my bandwidth: don't send ME back MY message when YOU reply.