Re: location of .h's in library

2004-06-19 Thread Alexandre Duret-Lutz
 David == David T Farning [EMAIL PROTECTED] writes:

 David 5. these header will be installed in prefix/includes via 
 David _include_DATA = 

include_HEADERS = ...

http://sources.redhat.com/automake/automake.html#Headers
-- 
Alexandre Duret-Lutz





Re: location of .h's in library

2004-06-18 Thread Daniel Reed
On 2004-06-18T13:50-0500, David T Farning wrote:
) I am working on my first attempt at building a library in c using
) automake.  I would like the verify the location and use of the header
) files.  Could someone verify or correct my assumptions.
)
) 1. headers internal to the library should located in /src
) 2. those headers should be dependencies under _SOURCES =
) 3. follow normal header rules of one .h per .c
)
) 4. public prototypes should be located in /includes
) 5. these header will be installed in prefix/includes via
)   _include_DATA =
) 6. use very few public headers to prevent the need for library users
)   to need many #includes.

Your proposal may make sense for your particular project, but there is no
specific standard.

You should split your headers whichever way makes the most sense for your
project's API. Arbitrary rules like one header per source file do not get
you much (unless your code is already hopelessly disorganized).

Package-specific headers should probably installed using pkginclude_HEADERS,
which will default to /usr/local/include/PACKAGE/. This may include things
like primary interface headers (data types and function protocols) as well
as any internal headers needed for special purposes (modules, extensions,
etc.).

Artificially reducing the number of #includes is probably not worthwhile. If
it makes sense to break your public interface into several headers, go for
it. An example might be if your library has a standard or simple
interface, and an additional advanced interface that allows finer-grain
interaction. Another may be if your library has multiple uses, and it is
conceivable a developer may wish to use one portion but not the rest.

(So, don't split by source file, but do split by component or task.)

-- 
Daniel Reed [EMAIL PROTECTED] http://people.redhat.com/djr/   http://naim.n.ml.org/
Murphy's Law is recursive. Washing your car to make it rain doesn't
work.




Re: location of .h's in library

2004-06-18 Thread Andrew Suffield
On Fri, Jun 18, 2004 at 03:13:55PM -0400, Daniel Reed wrote:
 (So, don't split by source file, but do split by component or task.)

Split your source files that way too. Then you get the one header per
source file effect most of the time - but it's completely
coincidental (sometimes you get several source files to one header; if
you've got several headers implemented in one source file, you're
probably doing it wrong).

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- --  |


signature.asc
Description: Digital signature