Re: Dumb shlib build rules cause regression test failures

Dear Tom,

> The obvious solution to this is to use Makefile.shlib all the time,
> but there's a problem: Makefile.shlib is only designed to build a single
> shlib per build subdirectory, and contrib/spi wants to build several.
> I don't see any easy way to rejigger Makefile.shlib to support multiple
> shared libraries at once --- anyone see a way?
>
> A klugy workaround is to build all the modules in contrib/spi into a
> single shared library.  This is ugly but I can't level any worse charge
> than "ugly" against it.

If I just want one extension, I would like to load only that extension. So
I'm really against an artificial "ugly" merge. But it seems ok to me if it
is not artificial.

> The other contrib modules build no more than one shared library apiece,
> and could trivially be converted to the MODULE_big build path.  Or more
> likely, redefine the MODULES case in pgxs.mk to support only one module
> in a directory, and use Makefile.shlib all the time.

If the makefile needs a lot of work to build several shared libs, I would
suggest to split contrib/spi and possibly others on a one shared lib per
directory basis: contrib/spi_this, contrib/spi_that, contrib/spi_thing,
and thus to rely on Makefile.shlib all the time as you suggest.

Directories are cheap, and I don't think it is bad to separate different
contributions clearly.

On the other hand, if some distinct libs really belong together, then
merge them.

Just my very humble little opinion;-)

Have a nice day,

-- 
Fabien Coelho - coelho@cri.ensmp.fr