FreeTDS Development Group

[Brian Bruns <camber AT ais.org>]

On Tue, 30 Oct 2001, James Cameron wrote:

> Brian Bruns wrote:
> > configure doesn't do it for me...it leaves the string defined as
> > %SYSCONFDIR%...I'm totally open to alternate ways of doing this.
>
> The way it was is correct, I was wrong.  The configure.in change you
> committed (revision 1.6) is fine.
>
fair enough...didn't actually mean to check that one in...it was in my
local tree when fixing Eric problem...

> GNU coding standards require that substitutions of source be done in
> Makefile, so that the code can be rebuilt with a different prefix
> without having to reconfigure.
>
> I tried changing it to @SYSCONFDIR@ (which is what configure works with)
> but all I got was ${prefix}.
>
> The use of include/tds.h and include/tdsver.h in AC_OUTPUT might not be
> complaint with the standard; we should be using a config.h file instead.
>
Ok, we have a config.h file now.  Let's see what is needed, looks like
@smallint@ type stuff in tds.h, not sure how to deal with that one. I
don't want to introduce a tds.h dependancy on config.h (tds.h is needed
by user programs...and config.h is not distributed with make install).

Looks like tdsver.h[.in] could go away entirely.  All the info is in
config.h

> References:
>
> http://www.gnu.org/manual/autoconf-2.52/html_node/autoconf_23.html
>
> "Variable: sysconfdir
>       The directory for installing read-only single-machine data.
>
> Most of these variables have values that rely on prefix or exec_prefix.
> It is on purpose that the directory output variables keep them
> unexpanded: typically `@datadir@' will be replaced by `${prefix}/share',
> not `/usr/local/share'.
>
> This behavior is mandated by the GNU coding standards, so that when the
> user runs:
>
> `make'
> she can still specify a different prefix from the one specified to
> @command{configure}, in which case, if needed, the package shall hard
> code dependencies to her late desires."

What about the make maintainer-clean stuff you were talking about, that
should still remove tds_configs.h, no?

Brian