[fdo-dev] fdo and fdocore
greg.boone at autodesk.com
Fri Jul 7 16:46:48 EDT 2006
Thank you for your valuable feedback. We appreciate all of your comments.
From: Mateusz Loskot [mailto:mateusz at loskot.net]
Sent: Friday, July 07, 2006 4:40 PM
To: dev at fdo.osgeo.org
Subject: Re: [fdo-dev] fdo and fdocore
Greg Boone wrote:
> [GB] See inline...
> -----Original Message-----
> From: Mateusz Loskot [mailto:mateusz at loskot.net]
> Sent: Tuesday, July 04, 2006 8:05 PM
> To: dev at fdo.osgeo.org
> Subject: Re: [fdo-dev] fdo and fdocore
> Hi Greg,
> Greg Boone wrote:
>> You may also wish to read the OpenSourceBuild__README.txt file located
>> in the root of the fdocore Subversion. This file also contains some
>> information that may be useful in your efforts to build FDO and the
> Yes, I've read this file.
>> While the fdocore.osgeo.org subproject contains source code for the FDO
>> API, the fdo[ProviderName].osgeo.org projects contain the source code
>> for each provider. The web sites for these projects contain minimal
>> documentation at this point and users are expected to gain access to
>> these subprojects primarily through the fdo.osgeo.org site. It is my
>> expectation that not users will be given access to all providers but
>> that access will be given on an as needed basis.
> I understand.
> So, only developers, testers, contributors and involved users will
> have access to particular provider project.
>> Each provider subproject is setup in a similar manner with the source
>> code being organized....
>> The inclusion of Providers at the top of the source code tree was not
>> absolutely required but was done to maintain a visual link with the
>> source in fdocore and encourage the location of provider code in a
>> directory structure that intertwined with fdocore. In this manner the
>> fdocore build scripts can be used to build the providers as well. Using
>> the checkoutsvn script is an easy means of correctly setting up the
>> proper directory structure.
> I understand.
> Good idea.
> Though, personally I checkout FDO projects to my own structure a bit
> different but it's not a problem as you explained in one of previous
>> For building purposes, each provider under .../Provides/[ProviderName]
>> has a separate configure build script and a version of build.bat and
>> build_linux.sh that is specific to that provider. These scripts can be
>> called directly. If these scripts are called directly, ensure that the
>> following environment variables are set as outlined in the fdocore
>> setenvironment script:
> I understand.
> Here I'd like to ask additional question.
> As I understand, building any of the fdo[ProviderName] projects require
> to have complete source tree of the fdocore.
> And if I have built fdocore separately and I have fdocore
> libs and headers installed it's still not enough to build provider,
> the whole fdocore tree is required.
> And those variables listed above should point to locations in the
> fdocore tree.
> Am I right?
> [GB] Yes. This is correct.
> Is there a plan to change it? To enable builing providers with fdocore
> installed only?
> [GB] No, not at this time
I understand it.
>> Regarding the unit tests, the tests located in .../Fdo/UnitTest have
>> been developed exclusively for the FDO API. These tests do not apply to
> I tried to run the UnitTest but it failed.
> Here is the last message:
> Test name: 7XmlTest.testXsl
> Failures !!!
> Run: 99 Failure total: 1 Failures: 1 Errors: 0
> Note, the strange characters above, something like binary output.
> Do I need to do any configuration for the UnitTest?
> [GB] So, only 1 test failed? No setup should be required.
> I will retry the unit tests and see if I can reproduce.
Now, we're taking ~2 weeks break from FDO projects, but when I am
back to it near the end of the July, I'll do deeper tests and provide
>> If test data is required for the unit tests to run, the test data will
>> be located under .../Providers/[ProviderName]/TestData. The test data
>> for the GDAL provider are located under .../Providers/GDAL/TestData.
> I see.
> What about environment configuration?
> Anything should be set?
> [GB] No, I do not believe so.
>> For Linux, ensure that make install is run for the provider you are
>> testing so that all binaries are installed in the default install
>> directory /usr/local/fdo-3.2.0/lib.
> Does it mean I should not use custom installation prefix?
> [GB] We have not tested with this option so I would defer using it at this time.
OK, it's clear now.
> Also, is this required to install providers under the same prefix as
> [GB] Yes.
Hmm, that may be the reason. I installed fdogdal to different prefix
> Last questions I have are about directories naming convention used in SVN.
> As I see, in the old fdo sources tree are use lower-case names.
> In the new fdocore tree all directories are named with first letter
> upper case. Is this intentional convention?
> [GB] Yes, Our convention has *primarily* changed to camel case directory names
> On Windows, names case does not matter but on Unix some unification
> would be helpful.
> In example, if on Windows someone on write
> #include <fdo/raster/myfile.h>
> but the path is Fdo/Raster/MyFile.h
> then it won't compile on case sensitive systems.
> So, please tell me what is the dirs naming standard to follow.
> [GB] The convention is to *generally* use camel case directory and file names.
OK, now it's clear.
Greg, thank you for your great support.
To unsubscribe, e-mail: dev-unsubscribe at fdo.osgeo.org
For additional commands, e-mail: dev-help at fdo.osgeo.org
More information about the Fdo-internals