Hi,
I'm remaking gdal and grass packages (as well as qgis and maperver) now. Here is my plan after some feedbacks were recieved. Any comment is welcome.
In general, when I make a package, the package should have variants like this:
foo-ssl - ssl version. have all the possible compile options.
foo - have all the possible compile options.
foo-nograss and foo-ssl-nograss - no grass support.
foo-nopgsql and foo-ssl-nopgsql - no postgresql support.
This way, people can expect foo-ssl or foo to have everything. For example, MySQL is starting to have MyGIS, just like PostGIS or Oracle's Spatial thing as I understand. In the future, the packages should have MyGIS support. If you want to save compile time or some dependency failed, you can still go for noxxx variant.
I think this way better as there are many options with GIS packages which ordinary users don't want to care. I also think providing all the options would be better than otherwise. As I figure out to have more options, I will update the package, so people can just run fink update-all or something to use the new feature.
On May 20, 2005, at 12:03 PM, Blair Zajac wrote:
Actually, there will be cyclical dependency -- is it possible to
configure/install gdal-grass 1.2.6 from WITHIN the grass5.7 .info file with
the right flag (--with-grass=%p/share/grass-%v)? The gdal-grass requires
grass 5.7 to install, but as far as I can tell you can install grass without
it, and when you get gdal-grass installed the gdal-specific grass commands
will just start working (e.g. I don't think you'll get an error if you use
--with-gdal even if gdal isn't currently installed).
As I mentioned earlier, I am thinking to have -nograss variant, instead of -grass for most packages except gdal. gdal is exceptional because gdal and grass depends on each other. So, do we want like this?
gdal - without-grass gdal-grass - with-grass grass-nogdal - without-gdal grass - with-gdal
If you want to have gdal-grass and grass, you first install gdal and grass, then replace gdal with gdal-grass. A bit tricky, though.
Alexis Zubrow wrote:
Hi Blair.No, it's not missing but deliberately turned off. It needs to be added. Any patches to enable this with support for Python 2.3 and 2.4 would be great. I don't have time now to add this myself.Thanks for the info. I ended up installing it from source. After going back and forth w/ Frank Warmerdam, I came up w/ a hacked solution.
I wrote a little install howto:
---
Building shared libraries on a Mac is a bit tricky. In order to build
the python wrappers for gdal and pyIoapi, you first need to set an
environment variable:
$ export MACOSX_DEPLOYMENT_TARGET=10.3
At the time of this document, gdal version 1.2.5 would not build with
python support. If you get one of the nightly cvs snapshots, this
will build if you run:
$ ./configure --without-libtool
This should build without errors. But, the python modules does not
work with a fink version of python. To solve this problem, go into
the pymod directory under gdal, and recompile the module:
$ g++ -bundle -undefined dynamic_lookup gdal_wrap.o
numpydataset.o gdalnumeric.o -L.. -lgdal -L.. -lgdal -lnetcdf -lz
-ldl -L/sw/lib -lpq -o _gdalmodule.so
In addition, the cvs snapshot does not completely install. After
running its install, copy the following files from pymod to your
python module directory: _gdalmodule.so, gdal.py, gdalconstants.py,
osr.py, ogr.py.
Python support is one of my wished option for gdal. I will try it with the next revision of gdal-1.2.6 after the grass-gdal cross dependency is solved.
-- BABA Yoshihiko
------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
