[FGS] Source Cache, CVS access

[Julien-Samuel Lacroix]

Hi,
One thing I've noticed is that it's easier to compile PHP (more 
user-friendly maybe) than other packages because it take cares of it's 
modules. The drawback is that it's not always clear which module are 
available once the compilation finish.

When compiling PHP and all modules you only have to do:
$ fgsdev build_pkg php
in your case it will be:
$ fgsdev build_pkg gdal
$ fgsdev build_...

Julien

Daniel Morissette wrote:
> Frank Warmerdam wrote:
> 
>>
>> I did my prototype gdal_ecw module for the ECW plugin driver
>> according to the prototype of python_mapscript which has it's
>> own directory in pkg_def, and is explicitly listed in the build.list
>> file.  I see that mechanism and the approach used in the php case both
>> end up producing fgs-*-module*.tar.gz files so the final result
>> seems to be the same.  Do you see any compelling reason to do
>> things one way or the other?
>>
> 
> I don't know enough about how each way works to tell which one is best. 
> It just seemed cleaner to keep all sub-modules grouped under the same 
> directory as the main module, but if the result is the same then that 
> probably doesn't matter much.
> 
> 
>> I see the gdal_ecw and python_mapscript modules are specified in
>> the build.list file with the version number referrning to their
>> parent package (where their source lives).
>>
>> Currently GDAL doesn't really support producing plugins in a
>> convenient way, unlike PHP, so doing them as seperate packages
>> at least keeps the hackery distinct from the base gdal build.
>>
> 
> If that seems like a better approach then I'm fine with that for now. If 
> we find out later that the other approach has advantages we can always 
> make the switch in a future release.
> 
> Daniel

-- 
Julien-Samuel Lacroix
Mapgears
http://www.mapgears.com/