|Title:||macos, linux: configuration: unable to build using trunk|
|Submitter:||bll||Created on:||2019-05-13 22:13:54|
|Subsystem:||84. Unix Build||Assigned To:||nobody|
|Status:||Closed||Last Modified:||2019-05-15 18:17:39|
|Closed on:||2019-05-15 18:17:39|
On MacOS and Linux, in trunk, it is no longer possible to build Tk without an existing installation (that seems a bit quiet, it's much worse). The configure script currently expects the --with-tcl option to point to where the 'tclConfig.sh' script is located. In the past, the --with-tcl option would point to the Tcl build directory. There are numerous problems with the current configure script in trunk: - It is using an embedded Tcl script to run some sort of version check. - The embedded Tcl script is written for Tcl 8.6, and fails miserably with older versions. On MacOS, the Tcl shipped with the system is Tcl 8.5, and the script fails. - If there is no 'tclsh' found, the script resets the 'no_tcl' variable (which was set to true), and then fails. - There is no guarantee that the 'tclsh' found is a match to the 'tclConfig.sh' script that is found. - On MacOS, building a development tree, the configure script locates a tclConfig.sh script in the build tree. Tcl has not been installed yet, and using a tclConfig.sh script at this point is not valid. a) I think a decision must be made as what --with-tcl means. I have not gone through all the different versions to see when it changed, but changing its meaning is not a good idea. (The tcl8.0.5 configure script is borked, btw. How did it get shipped?). My opinion at this point: Remove --with-tcl entirely. This will force Tk maintainers to redo the build properly, and there will no longer be an ambiguous meaning for --with-tcl. --with-tcl-config : used to specify the location of a tclConfig.sh script. --with-tcl-include : location of the Tcl include files needed to build Tk. --with-tcl-lib : location of the Tcl libraries needed to build Tk. Then Tk can be built against an existing installation by specifying --with-tcl-config, or against a development tree (or other install) by specifying --with-tcl-include and --with-tcl-lib. If a system is missing its tclConfig.sh, the --with-tcl-include and --with-tcl-lib can be used to build Tk. b) Autoconf macros are available for version checks. c) The version number is present in the tclConfig.sh script. https://www.gnu.org/software/autoconf-archive/ax_compare_version.html Use the existing tools which work, not stuff that does not work at all. If the version number in tclConfig.sh is not valid, then the configure script should not use it at all. d) An existing, executable 'tclsh' is not required to build Tk. There's no reason to be running tclsh. e) When no --with-tcl-* is specified: If --prefix is specified, the first place to look for a tclConfig.sh is in the $prefix/lib directory. If --with-tcl-config is specified, that's the location for tclConfig.sh, not somewhere else. See: http://core.tcl.tk/tk/info/9a6ed28e98d31bc3 Essentially the current configure script in trunk is a royal piece of crap with numerous mistakes piled on top of each other. I don't care who did this or what they were thinking, that's not important. What's important is to rip that crap out with excessive force and replace it with a working system. Goals: a) Be able to build Tk against an existing installation of Tcl. b) Be able to build Tk against a specific installation when more than one Tcl version is installed. c) Default to doing the right thing when --prefix is specified, --with-tcl-* is not specified, and there is an existing installation at $prefix. d) If a search must be done for tclConfig.sh, check the version properly using the autoconf macros. Do not build against a mismatched version. e) Be able to build Tk against an existing installation using --with-tcl-include and --with-tcl-lib (assume no valid tclConfig.sh exists). d) Be able to build Tcl/Tk without installing Tcl using the --with-tcl-include and --with-tcl-lib macros. (For development testing) d1) MacOS d2) Linux e) Be able to build Tcl/Tk without it picking up random paths from previous installations. e.g. if I build once with --prefix=localB, then re-configure with --prefix=localC, it should not pick up configurations from localB.
pooryorick added on 2019-05-15 18:17:39:
Also, does adding a build-time dependency really require a TIP?
pooryorick added on 2019-05-15 18:15:46:
Fair. I want to do it my way. I much prefer to depend on Tcl than on bash. And Tcl should be a no-brainer, particularly for Tk.
bll added on 2019-05-15 13:38:09:
"As a matter of principle", really? Translated: "I want to do it my way" Build configuration tools are created to use the lowest common denominator. They do not use gnu-isms, gcc-isms. Only the necessary tools are used. autoconf, metadist, my package mkconfig use bourne shell and basic posix commands for a reason. Introducing a very high level dependency into a build configuration tool is not a good idea. The question to ask is why. Why is tclsh _needed_? Why is tclsh _necessary_? What is the need that makes it necessary? I do not think you can answer this question to anyone's satisfaction because tclsh is not necessary, and certainly tclsh 8.6 is not necessary. Opening tickets to try to fix that mess is not a good idea. Instead open tickets to address the original issues that are necessary to fix. As Jan has commented, why is there no TIP? Why are there no tickets addressing these issues? ---- I have right here CDs with 20 versions (1999-2002) of a script I wrote that automated the builds of 245 different software packages for Solaris. I made all (excepting just a couple hold-outs that had too many gcc-isms) of them compile and link with the solaris C compiler and I made all of them relocatable to /usr/local or /usr/lbin or /opt/local or whatever. (tcl/tk 8.3.4 are in the latest list). I've seen all the silly assumptions, gnu-isms, and gcc-isms that people make in their packages. I wrote my own build configuration tool that works very well across a wide variety of posix platforms.
pooryorick added on 2019-05-15 08:42:39:
To clarify, I'm talking about requiring version 8.6 to only as a build tool. It is still possible, of course, to link Tk against earlier versions of Tcl.
pooryorick added on 2019-05-15 08:40:56:
As a matter of principle, I think Tcl 8.6 should be required to build Tk. Obtaining a working Tcl 8.6. should be no obstacle for anyone building Tk.
jan.nijtmans added on 2019-05-15 08:18:24:
I re-opened the "buildtools" branch, based on current trunk, @yorick, your work is not lost at all!
jan.nijtmans added on 2019-05-15 07:58:01:
> The work was performed to remedy existing issues that are as significant as those noted in this ticket So, please, raise tickets for those existing issues. I see no reason to require an existing 8.6, the script could easily have been written for 8.5 too. Am I wrong?
pooryorick added on 2019-05-15 07:54:57:
I do not think the commit should be reverted. The work was performed to remedy existing issues that are as significant as those noted in this ticket. It's reasonable to require an existing tclsh version 8.6 or higher at build time. Rather than reverting this work, a series of more narrow tickets can be raised to deal with outstanding issues.
jan.nijtmans added on 2019-05-15 07:54:04:
Problematic commit reverted on trunk
jan.nijtmans added on 2019-05-14 21:35:52:
I agree that the best thing to do now is revert the mentioned commit. Pity for the committee ... But it can always be re-applied after the problems at fixed. I have no idea what this change was aiming at, a TIP describing that would have been nice, it would prevent our guessing ...
fvogel added on 2019-05-14 20:08:29:
Indeed Jan you are fully right: there is no issue with [a77eccdcf9bc8238]. The next commit however, that is [a9c9a75b5ba1f4a6], created the trouble. Well spotted!
So the issue really is here. I suggest this commit be simply reverted.
bll added on 2019-05-14 15:55:16:
Without testing, that checkin looks like the major breakage. This is really annoying François, as it affects his ability to test on MacOS.
jan.nijtmans added on 2019-05-14 14:47:13:
Did this trouble start with [a9c9a75b5ba1f4a6] ???
In other words: does the commit immediately before that ([a77eccdcf9bc8238]) work fine?