[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Installing gnulib headers with project

From: Bruno Haible
Subject: Re: Installing gnulib headers with project
Date: Thu, 04 Jan 2018 10:22:24 +0100
User-agent: KMail/5.1.3 (Linux/4.4.0-101-generic; KDE/5.18.0; x86_64; ; )


> Is there a way that I can install a gnulib header
> file with the rest of my project's installation?

The answer is different for POSIX headers and for utility module headers.

* In all cases, when you install such a header file, rename it.
  Rationale: Another package than yours may want to install the same
  gnulib header file. But the other package will likely use a different
  version of gnulib than your package. Bad things will happen if your
  package uses the other package's version of the gnulib header file, and
  vice versa.

* For POSIX header replacements, you should normally avoid to install
  gnulib-provided header files.
  - These header files represent workarounds which change over time.
  - These header files are tailored for a particular compiler, but the
    user of your public header files may be using a different compiler.
  - A good library API design means that your public header files use
    types that are independent of the interface between your library
    and libc or the kernel.
  However, in some cases, you want to use <stdint.h> files. This is hairy.
  Look how it's done in GNU libunistring.
  Alternatively, prefix the types: use my_uint32_t instead of uint32_t etc.

* For utility module headers (such as the gl_list.h in your case).
  I would try to get away without it, by presenting a purely functional API
  (rather than a data-oriented API). For example, instead of having a function
    gl_list_t my_foo (arg_t);
  define a type
    typedef struct foo_iterator *foo_iterator_t;
  and functions
    foo_iterator_t my_foo (arg_t);
    void foo_iterator_free (foo_iterator_t);
    foo foo_iterator_next (foo_iterator_t);
    void foo_insert (foo_iterator_t, foo);
  Rationale: The API of a shared library is easier to evolve without bumping
  the shared library major version number if the API is in such a functional
  Other than that, you *can* use a renamed gl_list.h in a public API. Just, be
  prepared to bump the shared library major version number more often. [1]



reply via email to

[Prev in Thread] Current Thread [Next in Thread]