[fdo-dev] 3rd party project issues
greg.boone at autodesk.com
Fri Nov 3 16:33:51 EST 2006
The use of the alternate environment variables sound like a reasonable
step in refining how FDO references thirdparty libraries. Log an
enhancement artifact in the fdo.osgeo.og Project Tracker. When I have
some time, I will look into the ramifications of making such changes in
the FDO Core and Provider project files.
As for creating a new SVN for 3rdParty, such a decision would need to be
taken as a part of a broader discussion on how to reduce the build
dependency of FDO on static builds of thirdparty libraries. In the
meantime, if you are not interested in updating/checking out Thirdparty
then you can write your own SVN scripts that avoid taking that
From: Baumann Konstantin [mailto:Konstantin.Baumann at hpi.uni-potsdam.de]
Sent: Friday, November 03, 2006 6:34 AM
To: Greg Boone
Subject: [fdo-dev] 3rd party project issues
My mail to "dev at fdo.osgeo.org" does not seem to get through, so I
forward it directly to you, as one of the most active poster of the
Sorry of the inconvenience... :-)
From: Baumann Konstantin
Sent: Friday, November 03, 2006 10:49 AM
To: 'dev at fdo.osgeo.org'
Subject: 3rd party project issues
I would like to suggest the following changes (at least for the
VS 2005 project files):
* use $(XERCESCROOT) instead of
* use $(XALANCROOT) instead of
* use $(GDAL_HOME) instead of $(FDOTHRIDPARTY)/GDAL13
* use $(BOOST_HOME) instead of ...
This allows to easily use your own more up-to-date versions of
And what about creating an additional sub-project "FDO 3rd
Party" (SVN: fdo3rdparty) which contains all the sources of the 3rd
party libs (instead of fdocore). This allows to download/checkout this
project only if you do not already have the corresponding
sources/projects, which could save a significant amount of memory and
svn-update-time (especially w.r.t. boost...).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Fdo-internals