[fdo-dev] fdo and fdocore

[Greg Boone]

[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

> NOTE that build_linux.sh is a helper script that assists developers to
> build the FDO components on Linux. We have many components in the FDO
> architecture and building them all was getting somewhat tedious using
> straight calls to configure and make. We also found that some developers
> were not interested in building all components or were only interested
> in building a subset of the components. 

I understand.

> The implementation of build_linux.sh script in essence calls...

As I prefer running ./configure manually with custom options, I
extracted those calls to separate sctipt called autogen.sh :-)

>     aclocal
>     libtoolize --force

I changed it to
libtoolize --force --copy

>     automake --add-missing --copy
>     autoconf
>     ./configure
>     make
>     make install
>
> ...for the fdocore components as well as the set of FDO providers that
> are currently supported on the OSGeo site. NOTE that building GDAL
> through the top level fdocore build_linux.sh script has not yet been
> enabled.

Good to know.

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

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

Also, is this required to install providers under the same prefix as
fdocore?

[GB] Yes.

> All unit tests are build on a cppunit framework. New test can be added
> by deriving the unit tests classes from the correct base class and
> calling the appropriate macros. Use the existing unit tests as examples
> of how new tests can be added.

I understand.

> However, I have run the existing unit
> tests for GDAL and noticed a few errors. I would recommend debugging and
> correcting these errors as a means of leaning how the unit test
> framework is establish and how it can be extended. 

Yes, those test are failing now but first we are cleaning fdogdal
project and running other non-unit tests.
UnitTest will be fixed soon.

> These two email have been a general overview on the structure of the fdo
> subprojects. I am sure that you will have additional questions....

Thank you for such a great story about FDO.
I'm sure those posts will very helpful and must-read for new FDO
developers.

I asked my questions inline. If I have new questions, I'll ask in new posts.
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.

Thank again

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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe at fdo.osgeo.org
For additional commands, e-mail: dev-help at fdo.osgeo.org