[KinoSearch] perl Build.PL error

[Marvin Humphrey]

On Jan 19, 2008, at 2:37 PM, Dobrica Pavlinusic wrote:

> Another one:
>
> dpavlin at llin:/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.com
http://www.rectangular.com/mailman/listinfo/kinosearch