Mark has certainly addressed my very limited number of concerns about this (except Python, snif). :-)
I agree as well with the point raised by ?? - let's all agree to maintaining developer interest by not asking them to keep maintaining 1.3.1 on PostgreSQL 7.4 Mark Cave-Ayland wrote: > Chris Hermansen wrote: > >> Ideally, all of us users out there should want to see an approach that >> makes builds "simple" for developers :-) >> >> But in the interesting situation where we users find ourselves needing >> to build some components from source (say, because GEOS in the Ubuntu >> repos is still at 2.2): >> >> Do you anticipate trying to make a PGXS-based build system for GEOS and >> Proj as well? >> >> Do you forsee this PGXS-based approach working well in conjunction with >> headers and libraries delivered through package managers like apt or >> yum? Speaking selfishly, I'd rather not see you make it easier for >> building on a windows platform at the expense of others... >> >> I guess a more productive way to make this comment is how do the >> developers see the user community doing builds? Do you need us to tell >> you when, why, how? > > Hang on a second. PGXS is a set of Makefiles provided with PostgreSQL > to facilitate the building of modules that link into the PostgreSQL > backend. It doesn't affect the build of GEOS or PROJ at all, and from > the user's point of view, a PostGIS build is still just "configure" > followed by "make install" for Unix-type systems. As a result of the > re-organisation, though, the code should stand some chance of building > reasonable under MSVC. But that will still require more testing. > >> It would be nice if Proj and GEOS dependencies also suggested to the >> builder that the latest version should be used... > > The current test code has full version checking for both GEOS and > PROJ, so please provide technical reasons as to which minimum versions > should be supported. From a purely selfish point of view, I'd be > tempted to make the minimum version of PROJ 4.5.0 since earlier > versions don't contain the right datum for correct OSGB transformations. > >> Too bad it wasn't possible to write the regression tests in Python. >> Why? Well, I think having some documented examples of good Python / >> PostGIS / PostgreSQL usage would be very helpful to the users thinking >> about coming over from an ESRI / Python environment... > > Perl seems to be the best choice as it is required for both the > PostgreSQL Unix and Win32 builds - hence it requires one less extra > dependency. It's also just regress testing, i.e. launching processes, > comparing output etc. rather than connecting using proper drivers and > doing useful work. > >> I didn't see official mention of the launch point for all of the above, >> but based on the preceding paragraph I'm assuming that all this Good >> Stuff will happen in 1.4, or 2.0, or something like that...??? > > Well some of the work has already started in SVN trunk. The next > release is slated to be 1.4, although who knows what may happen if new > features get added? ;) > > > ATB, > > Mark. > -- Regards, Chris Hermansen mailto:[EMAIL PROTECTED] tel+1.604.714.2878 · fax+1.604.733.0631 · mob+1.778.232.0644 Timberline Natural Resource Group · http://www.timberline.ca 401 · 958 West 8th Avenue · Vancouver BC · Canada · V5Z 1E5 _______________________________________________ postgis-users mailing list [email protected] http://postgis.refractions.net/mailman/listinfo/postgis-users
