Re: [HACKERS] Configure problem, redux (was Re: TCL installation troubles)

> "Thomas G. Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu> writes:
> > I started out with a Makefile.custom which has in it the following:
> > USE_TCL= true
> > TCL_LIB= -ltcl
> > X_LIBS= -L/usr/X11/lib
> > TK_LIB= -ltk
> > [ and it didn't work ]
>
> There is a comment in Makefile.global.in that says:
> # Please do not edit USE_TCL and USE_TK by hand.
> I dunno who put that in or why, but it seems relevant ;-)
>
> An offhand look at configure.in shows that it is also deriving values
> for TCL_CONFIG_SH and TK_CONFIG_SH, which need to be propagated into
> places that Makefile.custom can't reach. It looks to me like
> mkMakefile.tcldefs.sh is probably not coping gracefully if an empty
> string is substituted into it, which is what will happen right now
> if USE_TCL isn't set during configure. By setting USE_TCL in
> Makefile.custom, you made the Makefiles think that Tcl support is
> set up, but that doesn't take care of the subsidiary files.

Our tcl/tk suff was terrible in earlier releases. The new code from
Billy is quite nice. It looks at things the way tcl does. It looks for
tclConfig.sh in all the normal places, and gets the values from there.

We used to set those values manually, and had all sorts of tcl
version-specific tests that were certain to fail on many platforms.

> > Is someone prepared to fix up the Makefile to make it
> > more robust (e.g. it can't include a file which hasn't been constructed
> > yet, though there are ways around that by conditionally including it and
> > then running make from within that makefile).
>
> Well, *that* is not the problem here. GNU Make is smarter than you
> realize about files that are included into a makefile --- it will
> arrange to build the file if missing and then reread the makefile.
> The problem is an inconsistent set of configuration values caused
> by your hand-setting only some of the needed variables. And you can't
> even fix it by adding the missing variables to Makefile.custom.
>
>
> This brings up an issue that I had been planning to raise in response
> to Brook and Billy's disagreement a couple days ago about how to handle
> "libdir" in the Makefiles (thread "Configure problem (and fix)").
> Namely: I think we have gotten much too willing to use configure to
> rewrite subsidiary files all over the distribution, rather than ensuring
> that the configuration decisions are expressed in a central place.
>
> I believe it is considered good Autoconf style to emit a Makefile (or
> whatever) that is still hand-editable, so that one can go in and tweak
> the configure script's decisions after the fact. (In other words,
> Brook had the right idea as to style: libdir should be left unexpanded
> in all references, so that you can actually change it by hand in
> Makefile.global if you are so minded.)
>
> We have broken that capability entirely --- if you don't set a parameter
> to configure, you have little choice but to go and re-run configure,
> because chasing down all of the twenty or so output files that it
> generates is not very practical. (Which was Billy's point, or part of
> it; and he's right too.)
>
> This is not good, and it is not necessary. AFAICS there is *no* good
> reason that configure should be rewriting any subdirectory Makefile ---
> they all include Makefile.global, so anything they need to know could
> be stated, once, in Makefile.global. With a little more work we could
> probably make Makefile.global and config.h be the only files that
> configure creates at all. The various specialized shell scripts that
> configure is currently editing could be fixed so that they get their
> configuration info from the command line, whence it could be supplied
> from Makefile.global via the subdirectory Makefile that is invoking the
> script.

I disagree here. If people want to twiddle, they can after configure.
People would much rather spell params to configure, rather than to edit
Makefiles.

The use of configure as a centralized test mechanism is a great leap
forward for us. The basic problem is that Makefile's just can't do the
tests configure can, and any Makefile that needs a test needs a
Makefile.in, and is generated from configure.

Look in Makefile.global. It is huge, and very hard to understand, even
for veteran developers. I agree people should be able to twiddle with
Makefile.custom, but they MUST be required to supply the proper flags to
configure. We can't go down the road of allowing them to avoid the
'configure' flags, and somehow enable things in Makefile.custom. There
is no logical way to do that, and unless we want to prevent 'configure'
from doing the things it does so well, we will have to live with that
limitation.

I have my configure command and flags in a script and use run it as part
of the cvs update I do to keep my sources current.

--
Bruce Momjian | http://www.op.net/~candle
maillist(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026