Re: split module openat

[Jim Meyering]

Bruno Haible wrote:
> The module 'openat' is still a mix of two different functionalities:
>   - It provides the POSIX function openat(),
>   - It compiles the openat_proc_name() function on which the implementations
>     of fdopendir(), faccessat(), fchmodat(), fchownat(), fstatat(), mkdirat(),
>     mkfifoat(), mknodat(), readlinkat(), areadlinkat(), symlinkat(),
>     unlinkat(), linkat(), renameat(), utimensat() rely.
>
> So that programs that need one of these functions but not openat() don't
> include unnecessary code, it's advisable to split off the helper function
> openat_proc_name() from the openat() module.
>
> While doing this, I also noticed that openat.h has a number of dependencies
> (stdbool etc. - Paul removed 'dirent' from this list just yesterday), and
> it makes the dependency managemant easier if we can put openat.h in a module
> of its own.
>
> Here's the proposed patch. It also revisits the dependencies of all *at
> modules. Tested through a megatestdir on a dozen of platforms.
>
> It has the side effect that in packages that use 'fdopendir' but not 'openat',
> lib/openat-proc.c will now be compiled unconditionally, even on platforms
> that don't need it. This is mitigated through --conditional-dependencies,
> so IMO is acceptable.
>
> 2011-11-05  Bruno Haible  <address@hidden>
>
>       New modules 'at-internal', 'openat-h', split off from module 'openat'.
>       * m4/openat.m4 (gl_FUNC_OPENAT): Don't set GNULIB_OPENAT. Don't

Avoiding inclusion of unused code is welcome, and the cost+risk is
minimal (since you've done all the work and seem to have tested thoroughly).
This looks great.

Thanks yet again!