[postgis-devel] autoconfiguration for version 1.1.0CVS

alex bodnaru alexbodn at 012.net.il
Tue May 17 18:04:40 PDT 2005


hi strk

On Tue, 2005-05-17 at 18:16 +0200, strk at refractions.net wrote:
> >From an initial work I did on this approach I found myself forced
> into pre-costituted rules I didn't like to delegate to the
> pgsql source tree. In case we can simply use the *build* of
> the shared library (with no install) I agree on using it.
> 
the build part is the reason for my message, but after i took a look,
the install part is totally parametric, and i see no problem with it,
too.
>
> The pgxs stuff is at an initial stage and has been designed for
> small extensions. I don't think postgis is such a small extension.
> 
> I do see the "wasted" duplication effort of maintaining cross-arch
> build scripts in postgis when this is done in postgresql alread
> but did not handle to find an elegant solution to the "locking"
> problem.
> 
i beg your pardon, but i don't quite understand what the locking problem
is.
> 
> The approach suggested by Mark is the one I liked the most:
> use pgsql sources if USE_VERSION<800 or use pgxs otherwise.
> 
you have just stated that pgxs is made for a too small postgresql
extension.
> 
> Any help in implementing it w/out loosing the flexibility
> of deciding *where* to install the shared library is welcome.
> 
as i wrote above, the shared libraries installation is not mandatory in
Makefile.shlib, and if you decide to use it, the files will go to a
location provided in $libdir. this has a value provided by pg_config.
> 
> Note that Makefile.shlib (pgsql-src) and Makefile.pgxs (pgxs)
> are different, and need different threatment. My initial attempt
> was at providing a parametrized include in lwgeom/Makefile sourcing
> a local Makefile.shlib or the pgxs one. In that case we should be
> reproducing the pgxs mechanism locally.
> 
it seems, that there are no significant differences between
Makefile.shlib versions (except architecture additions), but in the
worst case, all could be provided in Makefile.shlib.$USE_VERSION for
about 30 kb on disk. sory to have omitted Makefile.pgxs in this
sentence.
> 
> Again. Any contribution is welcome. Just let's try to keep things
> simple. My question about which archs are people running postgis
> on was bound to knowing how large is the required archset and evaluate
> the required effort to support them all. Currently postgis build
> has been tested on GNU/Linux, Darwin and Mingw.
> 
keep your mind free. maybe there is a happy user of an exotic
architecture not attending the list?
> 
> About SONAME: can you tell me more about the lack of it ?
> What is it ? A variable for Makefile.pgxs ?
> 
it is a much more general issue. please see
http://wiki.linuxquestions.org/wiki/Library-related_Commands_and_Files#soname
Makefile.shlib does support it.

alex

>
> --strk;
> 
> On Tue, May 17, 2005 at 04:28:59PM +0300, alexbodn at 012.net.il wrote:
> > 
> > hello friends,
> > 
> > though the autoconfiguration of postgis should use only the publicly available postgresql 
> > information, i think we went too far with dropping usage of Makefile.shlib.
> > 
> > this file is a collection of information needed to make a shared library in the postgresql 
> > environment, as is stated in it's header.
> > 
> > although i agree it could be splitted in small files, each for a specific architecture, and 
> > included with the postgresql api, this information should be undoubtely used in the 
> > process of building postgis, which is a shlib itself.
> > please also note, that newer postgresql is only adding new architectures to this file, but 
> > it doesn't make other significant changes.
> > 
> > at the moment, the linux postgis library is lacking the SONAME, and this is the situation 
> > with other unices, too.
> > 
> > i would kindly ask you to reinclude Makefile.shlib dependency in postgresql, and in the 
> > most extreme situation, please include a separate Makefile.shlib for each supported 
> > postgresql branch.
> > 
> > best regards,
> > 
> > alex
> > 
> > _______________________________________________
> > postgis-devel mailing list
> > postgis-devel at postgis.refractions.net
> > http://postgis.refractions.net/mailman/listinfo/postgis-devel
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel



More information about the postgis-devel mailing list