[TCLCORE] Re: RFC/PEP format

[Brent W. <we...@aj...>]

>>>"Donal K. Fellows" said:
 > Andreas Kupries <a.k...@we...>

 > Do you have a document specifying the format of a TCT or is it simply
 > what you happen to have implemented?  :^)
 > 
 > > With respect to these drafts I would really like to get feedback
 > > from the people which did the TclBlast CD (TclBurn Team) and the
 > > Tclish installer. From everyone else too.
 > 
 > * I believe that the Tcl/Tk documentation is in HTML on Macs.

The tcl "tools" directory has a Makefile that generates the HTML for
the Tcl and Tk man pages.

 > * It'd be nice if there was a TMML browser written in Tcl/Tk.  Sure an
 >   HTML browser would be nice too, but being able to host our own
 >   documentation would be a definite plus.  :^)

The "Uhler HTML parser" is easily modified to understand different tags.
It is all table driven, and augmented with per-tag Tcl procs to do special
rendering.

 > * It might be nice too if there were several different SDK releases.
 >   I have in mind a version which is just a user-level one (i.e. one
 >   for people not doing heavy development, with only precompiled and
 >   pure Tcl extensions) and a version which is a developer-level one
 >   (with all the user-level stuff *plus* other tools which require the
 >   use of a compiler to work properly - SWIG and maybe tcl2c would be
 >   things to ship in this category.)  I suppose one is a collection of
 >   resources, and the other a full SDK...

Right - having lived through the latest TclPro release, in which I was mostly
a build engineer (we moved all of Tcl Pro into TEA for the first time for
TclPro 1.4) it isn't all that bad to have different suites of things that
get installed.  We did things in four steps:

1) make install
Do this for all the packages, and have a master dependency order between
modules so you build Tcl first, etc.  TclPro builds are complicated by
building static, dynamic, debug, non-debug for many modules because
TclPro wrapper needs static libraries.  For our purposes we could just
do a single build (in most cases) which is dynamically linked without symbols.
I could also see a "threaded build" that just has Tcl + Thread + whatever
other extensions are thread-safe.

2) make dist
This is not fully supported by all modules, so we ended up creating a master
"parts list file" that drove this process.  This copies stuff from the
area created by "make install" into a clean distribution area.  You can
also reorganize things a bit during this step.  Especially if you are
doing a cross-product of debug, non-debug, static and dynamic you need
this step to trim out junk you don't need.  If you only do a single
build in step 1) then the results of make install may be sufficient.

3) make installers
This is also driven by our parts list, which indicates which files are in
which sub-packages so you can have one installer but the user can pick
and choose what they want.  Especially if you do binary releases you can
have a bunch of platform independent files, and then slices for each
architecture you've build for.  Again, in a simplified form, you might
be able to just take everything produced by step 1 into a single, no choices
distribution.

4) Installation.  Here we do some patching of binary files to eradicate
traces of our build file system and make sure that TCL_LIBRARY etc. is
set appropriately.  It is awkward to get the -R path patched (this is
the equivalent of the LD_LIBRARY_PATH environment variable that gets
compiled into a binary so it knows where to find dynamic libraries.)
We could perhaps legislate the patching problem out of existence by
fixing the installation location, but I don't think that's very good.
I also patched the tclConfig.sh files so there was some hope of being
able to compile extensions against the installation - but we all know
that isn't fool proof because your compiler environment may differ.

--	Brent Welch	<we...@aj...>
	http://www.ajubasolutions.com
	Scriptics changes to Ajuba Solutions
	scriptics.com => ajubasolutions.com


--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.