marvin at rectangular
Jan 20, 2008, 2:27 PM
Post #4 of 9
(1260 views)
Permalink
|
On Jan 19, 2008, at 2:37 PM, Dobrica Pavlinusic wrote:
> Another one:
>
> dpavlin [at] lli:/data/KinoSearch/perl$ perl Build.PL
> Checking whether your kit is complete...
> WARNING: the following files are missing in your kit:
> buildlib/BBSortEx.pm
> Please inform the author.
Thanks. This one should have been fixed by r2926.
> build dies with:
>
> lib/KinoSearch.xs: In function 'XS_KinoSearch__Obj_STORABLE_freeze':
> lib/KinoSearch.xs:380: error: 'FileDes' undeclared (first use in
> this function)
> lib/KinoSearch.xs:380: error: (Each undeclared identifier is
> reported only once
> lib/KinoSearch.xs:380: error: for each function it appears in.)
> lib/KinoSearch.xs:380: error: expected expression before ')' token
> error building lib/KinoSearch.o from 'lib/KinoSearch.c' at /usr/
> local/share/perl/5.8.8/ExtUtils/CBuilder/Base.pm line 108.
That's an unrelated glitch I hadn't known about. r2933 should take
care of it:
- kino_OutStream *target = kino_OutStream_new((FileDes*)
file_des);
+ kino_OutStream *target = kino_OutStream_new((kino_FileDes*)
file_des);
> Should I just roll back my local development against latest CPAN
> version or
> pest more about errors like this? :-)
Here's what I recommend:
* If you don't need the features from the devel branch, use the
current
stable release.
* If you need the features of the devel branch, use the latest
devel release
(<http://www.rectangular.com/downloads/
KinoSearch-0.20_051.tar.gz>).
* If you find a bug in a devel release, write to the list. I'll
try to
address the problem and supply you with a number for a repository
revision I believe is reasonably stable.
It would be nice if the KS repository had a "stable trunk" policy,
but at this point, honestly, it doesn't. A pre-commit script might
help with MANIFEST glitches, missing files and such. However, the
real problem is that it's difficult to avoid memory leaks without
running the test suite under valgrind, which takes so long (c. 30
minutes) that I only tackle it every once in a while. Leaks are
almost never severe enough to bring down the test suite, but they can
easily cripple a long-running app.
Furthermore, the file format for trunk is currently in flux -- so
every time you update, you'd need to regenerate indexes just to be
safe. I try to remember to note file format changes in the commit
messages, but I've forgotten once or twice. It's hard to muster the
energy for really tight QC with every commit.
Of course it benefits me as a developer to have as many people as
possible using the latest svn checkout, but I don't think that's in
your best interest as a user. Maybe at some point I can get nightly
tarballs generating and provide a smoke test setup. Then at least
we'd get earlier warning when KS was failing, particularly for
systems that I don't develop on actively. A nightly smoke under
valgrind would be even better, but A) it would have to be set up, and
B) I don't currently have a box I could run that on.
Marvin Humphrey
Rectangular Research
http://www.rectangular.com/
_______________________________________________
KinoSearch mailing list
KinoSearch [at] rectangular
http://www.rectangular.com/mailman/listinfo/kinosearch
|
