Re: my frustration of last Friday:
> After beating my head against these incomprehensible new Makefiles, I
> found out why rpm kept dying. The INSTALL_ROOT variable that was put in
> the old Makefiles to support BuildRoot is now changed to DESTDIR. Why?
> Who knows? Anyway, I fixed my SPEC file and tried again, only to find
> that more than half the files aren't even getting installed. Why is
> it that
>
> make DESTDIR=$RPM_BUILD_ROOT install-strip
>
> doesn't install htdig.conf, search.html, rundig, any of the "common"
> files, nor any of the image files? Obviously, I'm not going to be able
> to build any RPMs any time soon, and I don't have the time to manually
> install everything I need to test out the new code. I've wasted too
> much time already. So, until I get some working Makefiles, I think my
> work on 3.2 is going on hold.
OK, after a very relaxing weekend, things are going better, and I was
able to figure this automake stuff out a bit more. As far as I can tell,
the DESTDIR stuff is mandated by automake. However, the transition was
only half done, so installdir/Makefile was still littered with references
to the old INSTALL_ROOT. After changing this to DESTDIR, I was able to
cleanly install all the files from there.
> In the meantime, if anybody else manages to get 3.2 working, could you
> please let me know if SGML entity decoding works correctly now, and if
> the problem of it stripping out bare &'s is gone? The new $%(var) and
> $&(var) template variable handling should now work too, but of course
> it's untested as well.
I guess I can answer my own question. :) The SGML decoding seems to
be working fine now, for the few HTML files I was able to test it on.
I also got the new $%(var) and $&(var) template variable handling after
a minor bug fix to htsearch/Display.cc. However, I'm running into some
memory problems. Right now, htdig is dying after indexing about 12 files.
According to gdb, it's dying with a segmentation fault in memcpy(),
but with trace prints I've tracked it up to when in calls fread() in
Document::RetrieveLocal(). This is tried and true code at this point,
so I can only assume that something before this has trashed memory.
I don't know if this is at all related to the memory woes that Geoff
mentioned last week, but I'm at a loss as to how to track it down.
I did take a look at HtVector, and found a few minor bugs, but that
didn't make a difference in my results.
> There were a few other things I had hoped to get
> into 3.2 if I had the time, but I only have 18 work days left before I
> go on vacation, and lots of other things I need to do, so I doubt I'll
> get much more done on 3.2 before I return in October. I expect you'll
> release 3.2.0b1 before then, so I'm not going to contribute more code
> I can't test.
The pressures on my time are still there, despite my taking a bit more
time to get to the bottom of last week's problems, so I hope other
developers can track down the memory leaks. I'll make an effort to get
a few more of my planned changes into the code, but failing that I'll
get them in sometime in October.
--
Gilles R. Detillieux E-mail: <[EMAIL PROTECTED]>
Spinal Cord Research Centre WWW: http://www.scrc.umanitoba.ca/~grdetil
Dept. Physiology, U. of Manitoba Phone: (204)789-3766
Winnipeg, MB R3E 3J7 (Canada) Fax: (204)789-3930
------------------------------------
To unsubscribe from the htdig3-dev mailing list, send a message to
[EMAIL PROTECTED] containing the single word "unsubscribe" in
the SUBJECT of the message.
