According to Brian White:
> At 09:10 6/09/2002, Gilles Detillieux wrote:
> >Well, while going with POSIX-compliant locking would help with
> >portability, I'm not sure all systems currently supported by 3.1.x
> >are fully POSIX-compliant either, so it may be that some only support
> >flock(), or even perhaps no locking at all.  Some configure tests for
> >various locking schemes should be implemented, so the code uses what
> >the system provides, or no locking at all if nothing appropriate is found.
> 
> I already have "locked" and "unlocked" versions of the code, managed by
> an #ifdef - I would just have to add a  -D__NO_FILE_LOCKING__ or something
> like that.

Yes.  Ideally, though, it would be automated via configure tests.
For example, you test for the flock() call and define HAVE_FLOCK
in htconfig.h.  Then the code uses #ifdef HAVE_FLOCK.  Similarly,
you define something like HAVE_FCNTL_LOCK if that capability exists.
That test is a bit more complex, as it's not just testing for the
existance of a library function.

> I assume this means I would need to create a patch for the configure
> script - any tips on how to do that? Is that monster *really* maintained
> solely by hand or is there some tools for it?

It's generated from configure.in by the autoconf program.  So,
configure.in is the monster we maintain by hand, which isn't quite as
big and scary as the configure script itself.  Still, you need to learn
enough about autoconf to get by, which is more than I know at this point.

> > > 3) It should be simple enough to create a patch that works with 3.2.x,
> > >     judging by a quick look at the latest Display.cc in the CVS repository.
> > >
> > > I *would* like to get it rolled into 3.1.x if I can. I am
> > > more than willing to make any changes required to make this
> > > happen.
> >
> >I think it would be good to see this in the 3.2 CVS tree, with the
> >appropriate configure tests.  I'm still a bit lukewarm on the addition
> >of the "init" input parameter to htsearch.  It seems the absense of a
> >"page" parameter would mean the same thing, wouldn't it?
> 
> You know, I hadn't even thought of that. The only disadvantage to it
> is that it isn't explicit - I can see someone setting "Page=1" for their
> initial search and wondering why their logging doesn't work. The only
> way around this would be documentation, with notes
> 
>     1) Where the "page" parameter is discuseed
>     2) Where the logging attributes are discussed
>     3) In the FAQs
> 
> Otherwise - Yes! Perfect!

Not to mention writing attrs.html entries (and links in cf_by????.html) for
all the new attributes.  This is of course easier in 3.2.

-- 
Gilles R. Detillieux              E-mail: <[EMAIL PROTECTED]>
Spinal Cord Research Centre       WWW:    http://www.scrc.umanitoba.ca/
Dept. Physiology, U. of Manitoba  Winnipeg, MB  R3E 3J7  (Canada)


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
htdig-dev mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/htdig-dev

Reply via email to