1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283
|
TODO
Test suites
Documentation
Last: Removal of old sources and build system.
=====================================================================
Proposal for a reorganization of the build system used by Img and its
supporting libraries.
=====================================================================
Glossary
--------
Up front a small glossary of terms to avoid confusion later.
[1] 'package library' (can be shortend to 'package').
A shared library having all the special code (xx_Init,
xx_SafeInit) to allow the tcl core to load it as a Tcl
package.
Examples: [incr Tcl], [Trf], ...
[2] 'support library'
A shared library which can not be loaded as a Tcl package.
Examples: libz, libjpeg, libpng, ...
Intro
-----
I propose to slash the existing source code into a number of separate
packages. I do _not_ propose to place each of these new packages into
a separate source tree. The files stay in the existing tree, and this
tree is augmented with additional directories containing the files
relevant to configuring and building the new packages. Essentially
configure.in and Makefile.in. All build systems will be based upon the
TEA 2 system introduced in the sampleextension (See Tcl SF project).
Note: I created the new build systems for TclXML/DOM/XSLT and their
various subpackages (expat, libxml2, ...) in this way, with success
IMHO :)
There will be one package containing the common utilities and one
package per image format, and support library [*]. The old name of the
package, Img, will be used to define a 'super'-package which loads all
of the existing functionality into the interpreter when required. This
maintains compatibility with existing scripts.
From the points of view of scripts there will be _no_ change in the
perceived functionality. It should however be easier to write
additional image format handlers using the framework provided by Img.
[*] As for why one package per support library see the next section.
Handling of the support libraries coming with Img
(and of support libraries) in general.
-----------------------------------------------------
Available options, discussion
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(1) Create the support libraries as part of the package for the
format requiring them. This is essentially a static linkage.
This one of the easiest ways to build a support library.
It also implies that the functionality a support library used
in multiple format handlers is loaded multiple times. To me
this a severe disadvantage.
(2) Create the support libraries independent of the using
packages, as shared libraries
(a) Link support at compile time into the packages.
(1) Via -library. In other words implicit usage of
the shared library loader provided by the OS.
Still relatively easy to do, although it
requires more care to portably generate shared
libraries. Libries used multiple times are
loaded only once.
Also requires a lot of additional support code
if the library a supporting library is linked
to is stored in and loaded from a non-native
filesystem. In other words when used in wrapped
application and such. The support code has to
copy the support libraries to the same place
in the native FS the using library is copied
to, _before_ the using library is loaded, so
that the support libraries are available to
the dyn.loader provided by the OS.
(2) Via direct usage of the objects. In other
words static linkage. This is the same as (1).
(b) Link support at runtime.
(1) Via explicit usage of the shared library
loader provided by the OS.
Generation of the support library is like for
(2a1). Loading however is done by explicitly
invoking the shared library loader of the
OS. This allows the Tcl library to perform the
necessary copying should the support library
reside in a non-native filesystem.
As the support library does not follow the
convention of a tcl package (per definitionem)
the standard load functionality of Tcl cannot
be used to load the library. This means that
(a) either the load functionality in Tcl
is refactored into
- portable low-level loading of
any shared library
- and high-level layer for
handling loaded shared
libraries which are tcl
packages.
(b) or the 'img' package has to carry the
source code implementing the portable
loading of shared libraries.
Option (b) I consider rather unpleasant as it
leads to the duplication of functionality in
all high-level packages requiring the loading
support libraries. Trf and TrfCrypt for
example have need of this functionality too.
(2) Wrap support library into thin package
exporting its functionality via a
stub-table. In other words, turn the support
library into a package library.
In contrast to (2b1) the support library is
not created as simple shared library, but with
all the necessary additional code to cause tcl
to recognize it as true package.
A stub table is used to provide the
functionality of the support library to other
packages.
This option could also be seen as (2b1c). It
makes the library available in a simple manner
with the need to refactor the load
functionality provided by the Tcl core. It
allows us to drive the reoganization of Img
independent of the Tcl core, making do with
the existing functionality. It also
essentially removes the impetus to actually
implement (2b1a). The good (enough) is the
enemy of the best.
Conclusion
~~~~~~~~~~
I have chosen option (2b2) for the support libraries. My reasons for
doing so are this:
* The state of the implementation of (2b1/1) is unclear. It
requires a TIP, and no movement is seen on that front.
The chosen option has no dependency on this vaporous
functionality.
* The chosen option allows us to use TEA 2 based build systems
for the support libraries themselves. They are easier to create
and later maintain, at least I perceive them so, due to the
larger number of existing TEA 2 based package I can draw upon
as templates for the new packages.
* Note that the chosen option does not prevent static linking of
the support libraries. Currently Img uses special code to
setup the function tables with static information when linking
Img statically. These function tables are essentially stub
tables. This means that the explicit usage of stub tables for
the support libraries makes this mode easier to handle too, as
no special code is required anymore.
* Note that the actually created package is also able use
-library to dynamically link to the actual support library. In
this mode it can make use of pre-installed libraries. In this
way we get a mixture of (2b2) and (2a1).
Files, and their organization into packages
-------------------------------------------
| Package | Stubtable | Files | Notes
-+---------------+---------------+----------------+------------------------
Ok | tkimg | Yes | img.h | Base package. Common
Ok | | | imgInt.h | utilities helping in
Ok | | | imgInit.c | the implementation of
Ok | | | imgObj.c | image handlers.
Ok | | | imgUtil.c |
-+---------------+---------------+----------------+------------------------
Ok | tkimg::bmp | | imgBMP.c | BMP format
Ok | tkimg::gif | | imgGIF.c | GIF format
Ok | tkimg::window | | imgWindow.c | windows
Ok | tkimg::xbm | | imgXBM.c | XBM format.
Ok | tkimg::xpm | | imgXPM.c | XPM format.
Ok | tkimg::ps | | imgPS.c | PostScript + PDF format
Ok | tkimg::jpeg | | imgJPEG.c | JPEG format
Ok | tkimg::png | | imgPNG.c | PNG format
Ok | tkimg::pcx | | | PCX format (Paintbrush)
Ok | tkimg::sgi | | | SGI format (SGI native)
Ok | tkimg::sun | | | SUN format (Sun raster)
Ok | tkimg::tga | | | TGA format (Truevision Targa)
-+---------------+---------------+----------------+------------------------
Ok | tkimg::tiff | | imgTIFF.c | TIFF format
Ok | | | imgTIFFjpeg.c | Various additional
Ok | | | imgTIFFpixar.c | codecs.
Ok | | | imgTIFFzip.c |
-+---------------+---------------+----------------+------------------------
Ok | tkimg::pixmap | | imgPmap.h | pixmap format
Ok | | | imgPmap.c | pixmap ? (PPM, XPM ?)
Ok | | | imgUnixPmap.c |
Ok | | | imgWinPmap.c |
-+---------------+---------------+----------------+------------------------
Ok | Img | | -- | Super package loading
Ok | | | | all of the above.
-+---------------+---------------+----------------+------------------------
Ok | jpegtcl | Yes | libjpeg/ | jpeg support library
Ok | pngtcl | Yes | libpng/ | png support library
Ok | zlibtcl | Yes | libz/ | zip support library
Ok | tifftcl | Yes | libtiff/ | tiff support library
-+---------------+---------------+----------------+------------------------
None of the '*Support' packages provides tcl level commands. They only
provide their own functionality, through stubtables. Note that the png
support library depends on libz, and thus has to require this package.
Misc. notes
-----------
* The zip support library (zlib, libz) is also used by
- tkHTML,
- JCW's 'zipper' package,
- zipvfs
- mk4vfs
- and Trf.
Placement of the ZlibSupport package with Img for the time
being is no problem and easy for tkHTML, as that package often
may want to use Img for the handling of additional image
formats in web pages. It is more of an issue when considering
zipper and Trf as there is more disconnect between them and
Img.
In the future we should move ZlibSupport into its own project,
or module in a project. Maybe directly into the source base of
zlib itself ?
The same can be considered for the PNG support.
Regarding JPEG the maintainership of the library much more
vague. In other words I don't know how to talk to for this.
* Regarding the code of img itself. Are the functions in
'imgObj' still necessary ? Especially ByteArray seems to
be a duplication of functionality provided by the Tcl core.
* Future: Reflect handler functionality into the Tcl level,
allow creation of format handlers in Tcl.
|