Re: [gamin] some portability stuff

[Daniel Veillard <veillard redhat com>]

On Sat, Sep 18, 2004 at 03:12:50PM +0200, Michael Banck wrote:
> Hello,
> 
> While trying to build gamin on GNU/Hurd, I noticed a couple of minor
> problems:
> 
> 1. gam_dnotify.c always gets compiled and results in build errors if not
> building on Linux.
> 
> The best thing for this would probably be a configure test, but I could
> not figure out how to do really do this. So I suggest to define
> ENABLE_DNOTIFY (similar to ENABLE_INOTIFY) (as well as ENABLE_POLLING)
> and only conditionally compile gam_dnotify.c in Makefile.am, just like
> with gam_inotify.c
> 
> 2. in gam_poll.c, some calls to st_mtim.tv_nsec are outside of #ifdef
> linux.
> 
> As this does not appear to be Linux-specific I suggest to add a
> configure test (from coreutils/make) for the st_mtim.tv_nsec struct
> member. Along this, the second call to this struct should be moved
> inside the #ifdef.
> 
> I have attached a patch for these suggestions. The actual naming of
> things might be not to your taste.

  Looked at it, applied to my tree, and then I forgot about it :-)
I'm a bit surprized by "ENABLE_POLLING" since even with DNOTIFY 
(and possibly INOTIFY) there are case where we use only polling for
some resources. Seems to me that ENABLE_POLLING means only that 
ENABLE_DNOTIFY and ENABLE_INOTIFY are not defined.

> Another problem I have not yet tackled is the unconditional use of
> PATH_MAX in fam.h and gam_poll.c. POSIX only says PATH_MAX should define
> the maximum path if the system actually has a limit. The GNU project
> does not impose arbitrary system limit. This means PATH_MAX is not
> defined on the GNU system, resulting in a build failure.
> 
> The clean way would be to allocate memory dynamically for char *filename
> and char *real, as filenames and paths seem to be a core business of
> gamin (other projects just #define PATH_MAX to something arbitrary if it
> is not defined). I do not know whether my C is good enough to produce a
> proper patch for this, so I would like to know what you think about this
> issue.

I don't want to allow too big path, and want to minimize dynamic allocation,
I think limiting path to a fixed lenght is a good thing in that specific case.

Daniel

-- 
Daniel Veillard      | Red Hat Desktop team http://redhat.com/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/