[fdo-dev] 3rd party project issues

[Greg Boone]

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
directory.

 

Greg

 

  _____  

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

 

Hi Greg!

 

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
mailing list.

 

Sorry of the inconvenience... :-)

 

Kind regards,

    Konstantin Baumann

	 

	
  _____  


	From: Baumann Konstantin 
	Sent: Friday, November 03, 2006 10:49 AM
	To: 'dev at fdo.osgeo.org'
	Subject: 3rd party project issues

	Hello everyone!

	 

	I would like to suggest the following changes (at least for the
VS 2005 project files):

	 

	* use $(XERCESCROOT) instead of
$(FDOTHIRDPARTY)/apache/xml-xerces/c

	* use $(XALANCROOT) instead of
$(FDOTHIRDPARTY)/apache/xml-xalan/c

	* 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
these libs...

	 

	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...).

	 

	Kind regards,

	    Konstantin Baumann

	 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/fdo_dev/attachments/20061103/0e04b5af/attachment.html