[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; ; ) |
Hi,
> 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.
Rationale:
- 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.
http://git.savannah.gnu.org/gitweb/?p=libunistring.git;a=blob;f=lib/Makefile.am
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
style.
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]
Bruno
[1]
https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html