RE: libraries

[Yves Arrouye <yves@realnames.com>]

> > Any well-known trick to compile the .c twice w/o changing 
> too much of the
> > original package? For example, does it make sense to 
> configure in two
> > different locations, once with --enable-shared and once with
> > --enable-static, for example? Do we have an example of a 
> small library that
> > does that?
> 
> For shared vs. static, this is not required, just compile 
> both and split
> the package regularly. For all other cases, the build rules 
> make of course
> call make distclean during the build or (even better) build in two
> different objdirs. The --prefix should always be /usr (as dh_make does
> it) because someone might choose to compile paths into the 
> binaries.

I'm not sure what "all other cases" are, I don't understand your answer :(
The policy manual says:

"All libraries must have a shared version in the lib package and a static
version in the lib-dev package. The shared version must be compiled with
-fPIC, and the static version must not be. In other words, each *.c file
will need to be compiled twice."

It says *must* everywhere, so I don't understand your "for shared vs.
static, this is not required, just compile both and split the package
regularly". I've looked at gdbm for example, and it does indeed do what you
call "all other cases" (except that it configures once and passes separate
CFLAGS twice apparently, which is fine by me).

In any case, since I'm one of the upstream maintainers of the package I'm
packaging, I just changed it so that it will compile both .o and .static.o
w/ different flags. But I'm still interested in clarifying your answer.
Thanks!

YA