[fdo-dev] fdo and fdocore

[Mateusz Loskot]

Hi Greg,

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:
>> Mateusz,
>>
>> 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
>> providers. 
> 
> 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....
>>
>> Providers/
>> 	[ProviderName]/
>> 		Docs/
>> 		Inc/
>> 		Src/
>> 		TestData/
> 
> OK.
> 
>> 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
> posts.
> 
>> 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:
>>
>> 	$FDO
>> 	$FDOUTILITES
>> 	$FDOTHIRDPARTY
> 
> 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
>> providers. 
> 
> OK.
> I tried to run the UnitTest but it failed.
> Here is the last message:
> 
> F.........................................
> UnitTestUtil.cpp:47:Assertion
> Test name: 7XmlTest.testXsl
> �p���y�p���z�p���<���(�p����l����p���C�(�p���r�z�(2
> 
> 
> 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
some feedback.


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


OK


>> 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
> fdocore?
> 
> [GB] Yes.


Hmm, that may be the reason. I installed fdogdal to different prefix
than /usr/local/fdo-3.2.0


> 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 


I see.


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

Cheers
-- 
Mateusz Loskot
http://mateusz.loskot.net