GHA obsoleted macos-12 so we move to macos-13 for Intel. Building with oldest
Intel image to provide feedback of continued expected support on that platform,
while ARM64 builds with latest to check the other end of their SDKs.
Lock the TCL version via brew to 8.6+ (currently the project is not expected to
build on TCL9 until other work is completed) so this is causing build failure.
Added additional diagnostics to show the location of executables/DSOs if they
got built from the tree.
Introduced GHA timeout clamping (MacOS default shell seems not to behave under
CI as well as Linux does, re signal/pipe handling)
'brew install tcl-tk@8' appears to append the @8 to the installed path such as
/usr/local/opt/tcl-tk@8 which configure needs to know. configure_mac updated
to detect this now TCL9 is the default version that maybe installed at the old
location. Then there is the issue of both TCL versions being installed
side-by-side on the same system causing more issues over selection.
There are 3 states for CLOSE_xxxxxx with 3 different values.
Issue introduced from 2f7f76bf9 merged since tag:8.3.509
This affected the scenarios using non-zero non-one values such as:
#define CLOSE_DONE 2
This looks the result of an original bug where the forward declaration
had a type mismatch with the real method, so the method implementation
prototype was taken as the correct one. The forward decl was rewritten
with the correct prototype signature.
Maybe this is the cause of CIF data once drawn into view does not always
seem to always erase after disabling and a redraw ?
This did not work as expected. Maybe that indicate this should have
a slighlt restructure so the tcl.h definition is always given a chance
to provide type.
Or maybe autoconf should detect the type and provide in config.h ?
This seems like it has 2 use cases.
Internal console management around reprinting command prompt, but many
modes of operation delegate the prompt processing to tkcon or readline.
Process termination to restore the termios.
In the TCL8 to TCL9 porting information it was indicated the
sentinal NULL termination should be cast (char *) with API
call Tcl_AppendResult().
This was already in place for most of the codebase this
resolves the last few places.
The Tcl_Exit() replacement proc takes charge of calling exit()
So this function can be easily migrated to libc atexit() which will
now run during exit() not just before. Which seems ok for the purpose
of restoring the termios state of the tty.
This solution seems compatible with TCL8 as well so all calls to this
removed API are removed.
Note this patch also removes the invalidation (of the callback so
the deefault use of Tcl_Exit() is restored) before returning from
this function. atexit() usage can not be invalidated after
registration but that can be controlled with application flag
checked inside the callback function if needed.
I have observed scenarios where I need to issue 'reset' manually
after exiting magic, still understanding better the build types
and scenarios that triggers this.
Legacy compiler support macro provided by TCL from a time when 'const'
did not exist.
This looks like it was put in place around the time of TCL 8.4
(from 2002 until 2013) which introduced APIs with 'const' types,
that were previously non-const. Probably due to legacy compiler
support across target platforms at the time.
Since the minimum TCL level is hardwired to 8.5 (from 2007 until
2016) it does not seem like that compatiblity is a current
requirement.
Now a (void *) but previously an integer.
These macros resolve the codebase allowing it to be built against both
tcl8 (8.5, 8.6) and tcl9 (9.0).
tar -zxvf tcl9.0.0-src.tar.gz
cd tcl9.0.0/unix
./configure --enable-symbols --prefix=/opt/tktcl9
make install
tar -zxvf tk9.0.0-src.tar.gz
cd tk9.0.0/unix
./configure --enable-symbols --prefix=/opt/tktcl9 --with-tcl=/opt/tktcl9/lib
make install
cd magic
./configure --with-tk=/opt/tktcl9/lib --with-tcl=/opt/tktcl9/lib
Dereference of 'h' after calling freeMagic(h)
Found while putting in cast.
Initially this is what was thought however....
freeMagic() has this one allocation to free latency, which is a matter
to resolve another day.
Darryl L. Miles
Tim Edwards