[Gdal-dev] static libraries revamped (was: new build strategy
for org/orgsf_frmts/)
Amici Alessandro
alessandro_amici at telespazio.it
Thu Jul 24 10:56:56 EDT 2003
> Alessandro,
>
> While I don't quite understand the approach, my impression is this
> use of "ld -r" for partial linking is going to be problematic on
> some platforms. As such, I do not think we should be making the GDAL
> build mechanism depend on it.
>
> Can be find another approach?
sigh!
i see two possibilities:
1 - create an 'ogr/o' directory and move the library object there (same
trick used
in the frmts directories) -> GDAL_OBJ += ogr/o/*.o
2 - move the executables into an 'apps' directory and probably the library
objects
in a 'ocore' (or something like that) directory -> GDAL_OBJ +=
ogr/ocore/*.o
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)
cheers,
alessandro
More information about the Gdal-dev
mailing list