Thread: Why do we use Tcl's compiler and flags?

The only really interesting things that tclConfig.sh (and tkConfig.sh)
tells us are the names of various libraries.  But those names can be used
portably with any compiler, so I don't see why we need to subscribe to the
whole deal.  AFAICT, the rest (TCL_CC, TCL_SHLIB_SUFFIX, etc.) is merely a
help for people who don't know how to build shared libraries, but we do,
so we should use our own way.

Naah, don't tell me it breaks on HP-UX.  Make it work... ;-)

-- 
Peter Eisentraut   peter_e@gmx.net   http://funkturm.homeip.net/~peter

Tom Lane writes:

> However, it doesn't appear to me that we'll get rid of all that much
> cruft if we change.  We'll still need to find and read tclConfig.sh
> in order to find out such interesting things as which shlibs libtcl.so
> is dependent on.  Why are you concerned about fixing something that's
> not especially broken?

It *is* especially broken if the compiler referenced by TCL_CC does not
exist on the system.  This situation is not uncommon on commercial
operating systems if the user did not shell out the extra cash for the
vendor's compiler suite, but the vendor did provide a Tcl installation.
We hear these bug reports once in a while, mostly from Solaris users.

-- 
Peter Eisentraut   peter_e@gmx.net   http://funkturm.homeip.net/~peter

Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> Why are you concerned about fixing something that's
>> not especially broken?

> It *is* especially broken if the compiler referenced by TCL_CC does not
> exist on the system.

Um.  Good point... although I'd still say such an installation is
broken, since it'll preclude building most available Tcl extension
packages.  But we have gotten a lot of reports like that, so it
seems worth working around the problem.
        regards, tom lane

Peter Eisentraut <peter_e@gmx.net> writes:
> The only really interesting things that tclConfig.sh (and tkConfig.sh)
> tells us are the names of various libraries.  But those names can be used
> portably with any compiler, so I don't see why we need to subscribe to the
> whole deal.  AFAICT, the rest (TCL_CC, TCL_SHLIB_SUFFIX, etc.) is merely a
> help for people who don't know how to build shared libraries, but we do,
> so we should use our own way.

I think this may be a hangover from a time when Tcl was more likely to
know how to build shlibs than our own makefiles were.

However, it doesn't appear to me that we'll get rid of all that much
cruft if we change.  We'll still need to find and read tclConfig.sh
in order to find out such interesting things as which shlibs libtcl.so
is dependent on.  Why are you concerned about fixing something that's
not especially broken?
        regards, tom lane