automake
[Top][All Lists]
Advanced

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

Re: Advice on the project structure for a library


From: Jef Driesen
Subject: Re: Advice on the project structure for a library
Date: Tue, 03 Jun 2008 15:44:02 +0200
User-agent: Thunderbird 2.0.0.14 (Windows/20080421)

Warren Young wrote:
Jef Driesen wrote:
I don't really want to mandate a specific style to the users of my library.

[snip]

Suppose that in one of my public headers, I include one of the other header files, with <libfoo/headerx.h> style.

If your headers use the libfoo/header.h style, your users must, too. That's not consistent with your wish above.

Why is that necessary? Isn't the toplevel directory (where the libfoo/header.h is located) also included, even if the user is using a <header.h> include style? Or is that only true if the headers are installed in the standard /usr/include location?

To allow your users choice in the matter, your public headers should use this style when pulling in other headers from the same project:

        #include "my-other-header.h"

The use of "" instead of <> tells the compiler to look in the current directory before going through the list of other possible directories. This is exactly what you want when you don't know where the user has installed the headers. A side benefit is that it protects you if there is a my-other-header.h on the system in one of the other directories in the include path; the compiler will always use the right one.

That sounds reasonable to me. But I also checked a number of libraries on my system (cairo, gtk, just to name a few), and none of them has "header.h" includes. They all have <header.h> includes, with a few exceptions that have <libfoo/header.h> includes (openssl for instance). Is there another reason for that?

The code style you use in your examples is another matter entirely. One way to fix it would be to make a symlink in the examples directory:

        $ cd examples
        $ ln -s ../src libfoo

If you're using a VCS that understands symlinks (e.g. svn, but not cvs) and always target POSIX systems, you can keep the symlink in the repository, and add it to EXTRA_DIST so it gets put in the tarball.

If you're targeting POSIX only but can't store the symlink in the repository, you can create it in examples/Makefile.am:

        all-local:
                ln -s ../src libfoo

(It might have to be moved up to the top-level Makefile.am to have the operations go in the right order.)

If you have to deploy on non-POSIX systems, then you have no choice but to reorganize your source tree, as Ralf suggested.

I want to support Windows, so I can't use symlinks.





reply via email to

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