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

"Thomas G. Lockhart" wrote:
> All good points. I had the USE_TCL in my Makefile.custom because for the
> last few months/years that was the only way to get anything about tcl
> touched by the installation afaik. I'll take it out.
>
> But I'm pretty sure that doesn't explain all the breakage. Will continue
> testing a bit (I *really* need to get back to the docs!), but the first
> problem I saw was due to a missing file which was not built
> automatically, and if you don't do a clean install you won't see the
> problem again. That's why I could work with "cvs update -Pd" for weeks
> and not see the breakage introduced, because by that point a
> Makefile.tcldefs already existed.
>
> > It's awfully late to be fixing this stuff for 6.4, unless you want to
> > slip the release date again. But I suggest revisiting it for 6.4.1,
> > and trying to consolidate configuration decisions into as few files
> > as possible.
>
> I would strongly suggest that we fix it now, with small incremental
> changes to make it work as currently designed. Releasing it broken
> doesn't do much good.
>
> So, I'm not sure I understand what the current design is really supposed
> to do, but istm that we could do a conditional include of
> Makefile.tcldefs, and have Makefile.tcldefs be a prerequisite for
> $(PGMS). Like this:
>
> ifneq ($(wildcard Makefile.tclsh), )
> include Makefile.tclsh
> endif
> ...
> all: Makefile.tclsh
> $(MAKE) $(PGMS)
> ...
>
> Any redesign after v6.4 is released should probably wait for v6.5, since
> a v6.4.1 release won't get adequate testing. We managed to break the
> Linux port of Postgres for v6.3.1 for similar reasons.
>
> - Tom

The breakage with the missing file occured when you defined USE_TCL in
Makefile.custom. That caused the make file (probably in bin/plpgtcl) to try
to include Makefile.[tcl|tk]defs. Since that file did not exist, it tried to
build it by executing MkMakefile.[tcl|tk]defs.sh, which didn't exist because
configure did not build it since it did not know to build the tcl/tk support
files.

Now for my 2 cents worth in the configure debate.

Why use configure? Why not have a makefile and config.h file that would be
edited by hand to configure and build postgresql?

PostgresSQL is a large system with many build options. Do you want TCL
support? TK support? perl support? C++ libraries? Using autoconf and
configure makes correctly building PostgreSQL for many differenct
OS/architecture easier. If configure is going to be used, then we should use
it to configure the system and not make it easy or desirable to circumvent
configure. This mean discouraging editing of make files by hand, because
there is no way to know what side effects and problems will occur if hand
editing is performed. To this end, I believe that configure should only
subsitute fully expanded values. If you want to change the prefix directory
(or any other option that is handled by a configure command line option, then
re-run configure. That is what it is there for. If configure won't create a
buildable version of postgresql on your system, then fix configure and send in
the patches.

Of course, we are now entering into areas of philosophical differences which should make for interesting discussions :-)
--
____ | Billy G. Allie | Domain....: Bill(dot)Allie(at)mug(dot)org
| /| | 7436 Hartwell | Compuserve: 76337,2061
|-/-|----- | Dearborn, MI 48126| MSN.......: B_G_Allie(at)email(dot)msn(dot)com
|/ |LLIE | (313) 582-1540 |