G'day,
A report of progress I've made recently; I'd be tempted to release some items
soon, but believe that some polish, especially in the ldoc area, is highly
needed.
I've now come up with ways to easily and fairly painlessly manipulate
Tecgraf packages, using a Lua script that is informed by a package database:
* "repofetch": Use "svn update" to keep my repository up-to-date;
" "releasefetch": Obtain the Sources/Examples/Docs tarballs/.pdfs
of one or more specified project;
* "nuke": Nuke any one, or perhaps all, project files in a work tree;
* "unpack": Unpack a tarball based on the latest-known Subversion
repository;
* "patch": Apply patches to the unpacked tree of a project;
* "build": Change into the package's "src" subdirectory, and execute:
LUA_SUFFIX= LUA_INC=/usr/include/5.1/ LUA_BIN=/usr/bin LC_ALL=C make
* "gather": Create designated runfiles/dynamic-loading .so files, and put
them in to a "play" support area ("base/1/support"; the "1" is
historical). The user can then play with scripts that exploit the
IM/CD/IUP toolkit in "base/1/play". A script file, "play-lua-tec",
references this support directory extensively, so that a tentative
build/gather set, perhaps trialling different combinations of patches,
can be tried without a system install (and without requiring any
system privileges).
[The biggest pain that I know of, at the moment, is that each time changes are
committed to the repository, is that I have to manually create a tarball, and
modify the main script to tell the "unpack" command the new repository number,
because it composes a repository-tarball filename for the "unpack" command.]
Here's the bash script of "play-lua-tec":
#!/bin/bash
# Use subdirectory ../support to keep IM/CD/IUP runtime support files
# hidden from the play area. However, also prepend the same patterns
# for the play directory, so the user can preempt and/or add objects
# during operation.
LD_LIBRARY_PATH=".:../support:$LD_LIBRARY_PATH" lua \
-e 'package.cpath =
"../support/?.so;../support/lib?.so;../support/lib?51.so;" .. package.cpath' \
-e 'package.cpath = "./?.so;./lib?.so;./lib?51.so;" ..
package.cpath' \
-l 'luarocks.loader' \
$* \
-i
So, for example, the small Lua script that creates a simple PDF (cdpdf.lua)
is shown below, and the last line shows how easy it is to run with the
infrastructure that I'm building up:
$ cat cdpdf.lua
require"cdlua"
require"cdluapdf"
canvas = cd.CreateCanvas(cd.PDF, "test.pdf")
canvas:Foreground (cd.RED)
canvas:Box (10, 55, 10, 55)
canvas:Foreground(cd.EncodeColor(255, 32, 140))
canvas:Line(0, 0, 300, 100)
canvas:Kill()
$ ./play-lua-tec cdpdf.lua
------
So, in summary, it's a huge step forward for me to be able to build CD on
two significantly different GNU/Linux systems such as Gentoo and Linux Mint.
At present, there are compilation errors when building IUP, but I'm working
on this area.
------
There's one more script in the toolkit, which has casual associations to
the Tecgraf makefile/tekmake output format, which looks to find and collate
diagnostics from the compiler, and by collecting, collating and summarising
them in a concise fashion, provide a valuable report to the user. The key
idea behind this is that a compiler diagnostic may be warning of a real
underlying bug, and so it is preferable to demand, and maintain, a
zero-diagnostics policy, for all available compilers: If there are several
dozen non-buggy diagnostics that are currently tolerated in the code, and one
change is made which introduces a real bug, along with a warning diagnostic,
the implication of the change may be hidden (i.e. the value of the diagnostic
may be significantly diluted).
My script to parse the Makefile output is "parse-build.lua", and, as with
other components of my rig, I'll try to clean it up and document it more
neatly over the next few weeks, hoping to release it sometime in the next
month or so. [Some diagnostics relate to out-of-date third-party packages,
and it's hard, sometimes including potential license issues, to easily
integrate the latest version into the code, so I'll try to co-ordinate any
changes with affected parties.]
cheers,
sur-behoffski (Brenton Hoff)
programmer, Grouse Software
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users
