The tclpkg utility is an attempt to make it possible
to configure and build TEA-enabled Tcl extensions on Windows
without requiring the CYGWIN toolkit.
tclpkg configure is intended as a replacement for
the autoconf-generated configure shell script;
it reads autoconf input files (Makefile.in, etc.),
and substitutes @CONFIGVARIABLE@s with the appropriate values
for the target platform.
Unlike configure, which uses run-time tests to
determine the appropriate settings, tclpkg uses
a static database. Since the Windows platform is much more
homogeneous than the various Unixes, this should be feasible.
Real Soon Now. (IOW, sometime in the next year or so,
sooner if someone asks me about it.) A rough draft of
the implementation is available at
http://www.flightlab.com/~joe/downloads/; look
for tclpkg-0.0-YYYY-mm-dd.tgz.
If the package you're trying to install does not come with
a tclpkg.conf file, see the next section.
To configure and build the package, use:
tclpkg configure --compiler=msvc ... other options...
cd srcDir
make ;# or nmake
Available options:
- --compiler=...
- Specifies the compiler and build tools to use. One of:
- --compiler=msvc
- (Windows) Use Microsoft Visual C++, nmake, link, lib, etc.
- --compiler=bcc (not yet implemented)
- Use Borland C++.
- --compiler=gcc (not yet implemented)
- Use the GNU compiler collection.
On Windows, this option (will) also assume the use of CYGWIN.
- --compiler=native (not yet implemented)
- (Unix) Use the platform-native C compiler.
Note: many commercial Unixes come with a program called
cc, but which only compiles a language vaguely resembling
what C looked like 15 years ago.
--compiler=native does not mean this program.
The "platform-native" compiler refers to the real C compiler,
often sold as an additional package.
- --libtype=shared | static
- Specifies if you wish to build the package as a shared library (the default)
or as a static library (e.g., to link into a custom tclsh or tclkit).
On some platforms it is possible to build both with the same
set of compiler flags; on others you will need to make clean,
reconfigure, and recompile.
- ...others
- Run tclpkg help
To install the package, cd to the top-level directory and run :
tclpkg install ? --prefix=tcl_package_path
Unless you tell it otherwise, this will install the package in
the directory ${TCL_PACKAGE_PATH}/${PACKAGE}${VERSION},
where PACKAGE and VERSION are specified
in the tclpkg.conf file
and TCL_PACKAGE_PATH is determined by
file dirname [info library]
Unfortunately, tclpkg requires Yet Another Damn Configuration File.
Sorry, I tried to get by without one, but it doesn't look possible.
@@@ ... fill this part in...
Basically: format inspired by TIP 55 and RPM spec files;
config file divided into sections (%info, %build, %install, etc);
each section contains RFC-822 style 'Header: value' pairs.
%info section
- Package:
- Package name.
- Version:
- Package base version (major and minor numbers only, e.g., 8.4)
- Patchlevel:
- Full package version (e.g., 8.4a4)
- Summary:
- Short (1-line) description of the package
- Description:
- Longer description.
- Requires:
- Space-separated paired list of dependant packages and their versions.
(e.g., Requires: Tcl 8.4 Trf 2.1)
%build section
- ConfigFiles:
- List of files which should be generated from the corresponding *.in file
- ConfigRules:
- Extra configuration rules to add to the rules database.
%install section
- Scripts:
- List of [glob]-style file patterns specifying Tcl scripts to be copied
into the package installation directory.
- A working tclsh is available on the build platform;
we can use it to configure and install packages.
- By default, uses a single source directory instead of generic/unix/win/mac.
Most platform dependencies are usually abstracted away by Tcl and Tk.
For packages that do have enough platform dependencies
to warrant separate source directories, things get more complicated.
- Compile and link in the source directory; this saves headaches
related to VPATH, CYGPATH, backslash quoting hell, and many others.
(Update: Turns out compiling in a separate build directory
is easy to support to if GNU make is available. So we
can allow both.)
- Package shared library is named
${package}${nodots_version}${shlib_suffix}
on all platforms, instead of fooXY.dll on Windows, libfooX.Y.so
on some versions of Unix, libfooXY.so on others, etc.
... in rough order of priority:
- Add support for Borland C
- Implement tclpkg install mode, to install packages
- Add support for GCC on Windows
(In theory, cygwin/gcc users can just use the conventional TEA
configure scripts; in practice this rarely works.)
- Add equivalent of TEA_LIB_SPEC
- Add support for Macintosh users (??? what compilers???)
- Option to set TCL_INCLUDES, TCL_LIB_SPEC, etc., to reference
Tcl build directory instead of Tcl installation directory.
(This will probably have to wait for TIP 59 integration).