[Gdal-dev] static libraries revamped (was: new build strategy for org/orgsf_frmts/)

[Frank Warmerdam]

Amici Alessandro wrote:
> i wuold prefer the second solution, but moving the files in cvs is not nice,
> however
> you do. so, i'll bite the dust and implement solution n. 1 ASAP.
> 
> the reason i preferred the partial linking approach is that you avoid the
> '*' wild
> card in the dependencies. note that all the '$(MAKE) check-lib' logic is due
> to *.o
> having different meaning at the beginning and at the end of the build.
> furthermore,
> changing the configuration and rebuilding may result in stale object files
> going
> inside the libray if you don't 'make clean' properly.
> 
> so i think it has been a valuable quest... :(
> 
> ok, back to work:
> - a libtool patch is in the works
> - since i put my hands on a 4-way itanium2, i have the strong feeling that
> building
> 	with -j 4 is a good thing (read: gdal parallel build is broken!
> looking into it)

Alessandro,

I think perhaps it is time we moved the file list for into a seperate file
that can be included from different places.  So for instance, in gdal/ogr
we would have a file with a list of the basename of all source files to
be compiled into object.

The gdal/ogr/GNUmakefile would include this and use it to build it's object
list.  gdal/GNUmakefile could also include this to build the list of object
files to be pulled from gdal/ogr and to recognise dependencies better.

Ideally this file would also be used as the file list for the NMAKE files
somehow.  Perhaps the file should look like:

OGR_OBJLIST = ogrcore.obj \
               ogrspatialreference.obj \
               ...

This can be directly included on Windows in the NMAKE file, and used.
With GNUmakefiles we can pretty easily transform the variable list into
other forms.

I would suggest we start doing this with gdal/ogr, and if it works out
well, it can be applied to gdal/port, gdal/gcore, gdal/alg, and
gdal/ogr/ogrsf_frmts/.  I think for the near future we might still use
the object file directory hack for the actual raster and vector format
drivers, though the same approach could be applied there too eventually,
with some sort of rules to compose stuff based on the drivers actually
being built.

If you would like to implement the above, then proceed otherwise let
me know and I will take a crack at it.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent