Thu, 10 Aug 2000 11:27:51 +0200
> You really should document the fact that libol's class generation stuff
> requires scsh for its scripts to run, and syslog-ng uses a libol tool to
> rerun on the source files when they change. You might also add a
> functioning test to libol configure.in that will fail if scsh is not
> present instead of proceeding like it does now. Either and especially
> both of these things will save people time ;)
scsh is required only to hack on the sources, simply compiling it doesn't
require scsh. I may put in some comments though. ... I added this to the
Hacking on syslog-ng
Syslog-ng uses a nonblocking I/O, and OO library called libol. Libol uses
a preprocessor to generate object definitions and information for the gc
to collect garbage. Object definitions are structs and some small functions,
and are placed in a file named something.c.x or something.h.x. These .x
files are then included in the C source files.
This preprocessor is written in Scheme, and requires scsh to run, but is not
required to simply compile syslog-ng, since all needed .x files are included
in the distribution. If you change a source file though, the .x file needs
to be regenerated.
By default all generated files are included in the distribution
so scsh is only required if you want to change something in the source
If the change you apply, doesn't change object definitions you don't
need to rerun make_class, simply update the date of the .x file using touch:
> It might also be a good idea to bundle the OL library with syslog-ng
> directly; do you have other programs which use libol ? The reason I
> suggest this is because I was really thrown for a loop with the
> EINPROGRESS stuff out of connect() that was fixed for .18; I built
> syslog-ng with .17 and ended up tracing down the problem with TCP relay
> manually only to discover afterwards that it was right in the ChangeLog
> for the new libol :) But I did not think libol was involved with respect
> to IO in syslog-ng, only with that OO C stuff it seems to be (I can't
> tell what it is exactly because there is not any documentation that I
> can find). Anyways it might be a good idea to just bundle a stable
> libol with syslog-ng and only update that version concurrent with
> syslog-ng version upgrades.
yes there are other projects that depend on libol (b-wall), though I always
suggest distributor maintainers not to create a seperate package.
> Now I am not sure about my memory problems, does libol also do
> memory allocation for syslog-ng?
libol provides the garbage collection framework. syslog-ng uses a mark&sweep
libol was forked from lsh's I/O backend, you can read more about its
internals in the file /doc/HACKING from the lsh distribution.
PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1