Tk Source Code

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.

Also, does adding a build-time dependency really require a TIP?

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.

"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.

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.

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.

I re-opened the "buildtools" branch, based on current trunk, @yorick, your work is not lost at all!

> 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?

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.

Problematic commit reverted on trunk

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 ...

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 [https://core.tcl-lang.org/tk/timeline?r=buildtools|here]. I suggest this commit be simply reverted.

Without testing, that checkin looks like the major breakage.
This is really annoying François, as it affects his ability to test on MacOS.

Did this trouble start with [a9c9a75b5ba1f4a6] ???

In other words: does the commit immediately before that ([a77eccdcf9bc8238]) work fine?