Better fresh checkout build experience

[GoogleCodeExporter]

The fresh checkout build experience leaves much to be desired and can be 
improved a lot:

 * Lots of hardcoded C++ include/linker paths. Lots of strife if user doesn't have a D:\ drive.
 * No documentation stating what versions of 3rd party libraries are required. Including the required 3rd party libs in the repo would be even better
 * Missing projects (speedtest, GFastLib, gProjectPBuf, GeoSxRequestHandler, ut_geosx, GFastRenderer, WFSRequestHandler)

This is too much configuration required for a new developer interested in 
hacking and contributing to GeoREST (like me)

Original issue reported on code.google.com by jackie...@ennoble.com.au on 3 Jan 2012 at 1:51

[GoogleCodeExporter]

Understood Jackie, but a bit of resource starvation going on here :)

I've given your jumpinjackie account commit rights to the project. If you 
haven't been completely scared off and feel up to making any of these changes 
as you're working your way through the project, I'd be happy to support commits 
against this ticket with these changes.

We've been reluctant to include external libraries in the project repository 
because of the limited storage size that Google permits, but perhaps including 
zipfiles in the downloads area would work...

Here's some info provided offline to another developer by Simon...

How to build GeoREST on Windows:

3rd party libraries used in GeoREST:

POCO: http://pocoproject.org/  
GeoREST is build with the POCO version 1.3.6p2. 
http://sourceforge.net/projects/poco/files/sources/poco-1.3.6/
library folder: D:\Development\POCO\poco-1.3.6p2

ctemplate http://code.google.com/p/google-ctemplate/
ctemplate version 0.95
library folder: D:\Development\ctemplate\ctemplate-0.95

libkml http://code.google.com/p/libkml/
libkml version 1.0.1 
library folder: D:\Development\libKML\libkml-1.0.1

zlib http://zlib.net/
version 1.2.3 
library folder: D:\Development\zlib123

fastcgi http://www.fastcgi.com/drupal/
version 2.4.0 http://www.fastcgi.com/dist/fcgi.tar.gz
Build instructions.

1. Check/Edit the set_env_variables.bat file. Set the FDO and MapGuide and POCO 
path properly.

2. Build MapGuide ( v2.1 or v2.2  )

3. Build FDO ( version 3.5 )

4. Build 3rd party libraries.

5. Open command prompt and run set_env_variables.bat. Open GeoRest.sln file 
from this command prompt.

Original comment by ja...@jasonbirch.com on 3 Jan 2012 at 6:39

[GoogleCodeExporter]

The storage limits aren't *that* restrictive. I've stored in svn many binary 
releases of 32 and 64 bit FDO for FDO Toolbox in the past and never ran into 
quota issues. 

Original comment by jumpinja...@gmail.com on 9 Jan 2012 at 9:42

[GoogleCodeExporter]

Google gives us 4GB of combined space for code and downloads. 

Mars earlier proposed adding the 3rd party dependencies into the repository 
(I'll forward this conversation to you by email) and estimated the size at 1GB. 
I'd be worried that as we upgrade the dependencies, create branches, etc, etc, 
this would quickly exceed our quota.

I don't have any issues with the idea of maintaining a copy in Hg if this is 
shown not to be a problem.

Original comment by ja...@jasonbirch.com on 9 Jan 2012 at 6:41

[GoogleCodeExporter]

For the record, the 3rd party libs that I've added only added an extra 50mb to 
the repository quota. I made sure not to include the *compiled 
binaries/libs/intermediate files* which probably accounted for the bulk of the 
1GB.

Original comment by jumpinja...@gmail.com on 9 Jan 2012 at 9:34

[GoogleCodeExporter]

That seems pretty reasonable then... no objection to a check-in of this size as 
long as there's some kind of document (Hg readme.txt or wiki entry) detailing 
their provenance.

Original comment by jason.bi...@gmail.com on 10 Jan 2012 at 6:40

[GoogleCodeExporter]

The scripts and bundled 3rd party libs will not currently build for x64

You guys have 64-bit builds of georest for download so it is clear that you 
have 64-bit versions of these 3rd party libs in place to produce 64-bit builds. 
Rather than duplicate the effort, it would be nice if these changes to enable 
64-bit compilation were applied to the affected 3rd party libraries I've 
checked in.

Original comment by jumpinja...@gmail.com on 20 Jan 2012 at 12:58

[GoogleCodeExporter]

Main problematic 3rd party lib is libkml 1.0.1. It should be easy to 64-bit 
enable the other 3rd libs without issues.

The libkml source only includes 32-bit headers/libs, and offers no 64-bit 
versions of these libs or instructions on where to source these 64-bit versions.

Original comment by jumpinja...@gmail.com on 27 Jan 2012 at 8:12