Menu
▾
▴
[Tcl-bugs] [ tcl-Bugs-553544 ] spaces in paths break stuff
|
From: SourceForge.net <no...@so...> - 2004-12-09 19:44:51
|
Bugs item #553544, was opened at 2002-05-07 21:54 Message generated for change (Comment added) made by dgp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=553544&group_id=10894 Category: 51. Configure and Build Tools Group: obsolete: 8.4a5 Status: Open Resolution: None Priority: 5 Submitted By: Don Porter (dgp) Assigned to: Don Porter (dgp) Summary: spaces in paths break stuff Initial Comment: 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. ---------------------------------------------------------------------- >Comment By: Don Porter (dgp) Date: 2004-12-09 14:44 Message: Logged In: YES user_id=80530 After patch 1081595, this may become feasible. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2004-03-26 17:23 Message: Logged In: YES user_id=80530 8.5 development is happening. time to look at this again... ---------------------------------------------------------------------- Comment By: Mo DeJong (mdejong) Date: 2002-06-05 21:10 Message: 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. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2002-06-04 23:34 Message: 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) ---------------------------------------------------------------------- Comment By: Mo DeJong (mdejong) Date: 2002-06-04 22:31 Message: 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? ---------------------------------------------------------------------- Comment By: Mo DeJong (mdejong) Date: 2002-05-31 20:12 Message: 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. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2002-05-31 20:07 Message: Logged In: YES user_id=80530 Any objection to a commit? ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2002-05-09 22:18 Message: 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. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2002-05-08 17:30 Message: 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. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2002-05-08 02:36 Message: 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. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2002-05-08 01:35 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=553544&group_id=10894 |