Tcl Source Code

If the build directory or the --prefix install 
directory contains a space, the Unix build/install
goes haywire.

Here's a patch that enables building/installation.
I'm not 100% sure that it leaves the contents
of tclConfig.sh making proper sense, though.

Bleah.  This is still true.  Name to root directory of a Tcl source
code distributions to "space in path" and all the unix/* build
scripts fail.  Thanks GNU!

Logged In: YES 
user_id=80530

After patch 1081595, this may
become feasible.

Logged In: YES 
user_id=80530

8.5 development is happening.

time to look at this again...

Logged In: YES 
user_id=90858

The "just add TCL_DBGX to the extension's Makefile"
approach you suggest is how it used to be implemented.
The problems with this approach is what led me to
put those evals in the tcl.m4 in the first place.
What happens is the extension seems to work just fine
without the TCL_DBGX in the Makefile as long as you
don't build a static or debug version. When someone
comes along and build something other and a default
build, the linker fails because it tries to link to
a tcl library that is not there. We are not going to
go back to that impl.

I feel your pain when it comes to the quoting hell
of TCL_DBGX. The solution is to remove TCL_DBGX in
8.5 and come up with a new approach that will simplify
both Tcl and extension builds and allow installs
of multiple build types on one system. We don't need
to have multiple builds (static, threaded, etc) in
the same build dir. We just need to support multiple
builds in the same install prefix in 8.5.

As far as the immediate benefit people will see
from this patch, it just does not seem too important.
I would rather you hold onto this patch until 8.5.

Logged In: YES 
user_id=80530

I'll take the meta-question first.

No, this is not an urgent matter.  If we wait on this, Tcl's
configure
and build system will not be any more broken than it always
has been.
(I was *shocked* to see that GNU's install-sh is broken, too!)
These changes took quite a bit of effort, and if they were 
non-controversial, I hoped to let more people benefit from
that effort.

When you get back to this during 8.5 work, I eliminated the
"eval"s
in tcl.m4 because I could not come up with any way to quote the
space-containing paths in TCL_LIB_FILE, TCL_LIB_SPEC, etc.
in a way that would survive an eval.

Instead, by removing the evals, the values substituted into
extension
Makefiles still contain the literal characters $TCL_DBGX. 
But that's
not a problem, because the tclConfig.sh file also offers
that for 
substitution, so just add a TCL_DBGX definition in the extension
Makefile and things are fine.  (See Bug 554348)

Logged In: YES 
user_id=90858

First off, why did you remove the following code
from tcl.m4?

-    #
-    # eval is required to do the TCL_DBGX substitution
-    #
-
-    eval "TCL_LIB_FILE=\"${TCL_LIB_FILE}\""
-    eval "TCL_LIB_FLAG=\"${TCL_LIB_FLAG}\""
-    eval "TCL_LIB_SPEC=\"${TCL_LIB_SPEC}\""
-
-    eval "TCL_STUB_LIB_FILE=\"${TCL_STUB_LIB_FILE}\""
-    eval "TCL_STUB_LIB_FLAG=\"${TCL_STUB_LIB_FLAG}\""
-    eval "TCL_STUB_LIB_SPEC=\"${TCL_STUB_LIB_SPEC}\""


I have to admit, this patch gives me a bit of an
uneasy feeling. Is there some reason this patch
is needed right now? Can it wait until 8.5 when
I plan on rewriting everything to use only one
set of build macros? The Unix build system has
*never* supported paths with spaces in them.
Why start now?

Logged In: YES 
user_id=90858

Umm, let me take a look at it. I have been a bit
busy but I will get to it.

Logged In: YES 
user_id=80530

Any objection to a commit?

File Deleted - 22686: 



File Added - 22802: space.patch

Logged In: YES 
user_id=80530

Here's a revised patch that solves the problems
and leaves the tclConfig.sh contents in a state
that a suitable patched Tk can deal with.  See
a companion patch in the Tk project.

Logged In: YES 
user_id=80530

Trying to build Tk confirms that the tclConfig.sh file
produced by this patch is unusable.  More revisions needed.

Logged In: YES 
user_id=80530

Nope, that problem was just a bug in unixInit.test.

This patch works for me; still the unknown issues of
a proper tclConfig.sh and whether I've broken anything
on other platforms left for maintainer review.

Logged In: YES 
user_id=80530

The patch appears to be faulty in how it embeds
TCL_LIBRARY and TCL_PACKAGE_PATH into tclUnixInit.c.

File Added - 22686: space.patch