Issue 26 in georest: Better fresh checkout build experience
geo...@googlecode.com
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 26 by jackie...@ennoble.com.au: Better fresh checkout build
experience
http://code.google.com/p/georest/issues/detail?id=26
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)
geo...@googlecode.com
Cc: hkurta...@gmail.com simon.pe...@gmail.com ja...@jasonbirch.com
Comment #1 on issue 26 by ja...@jasonbirch.com: Better fresh checkout build
experience
http://code.google.com/p/georest/issues/detail?id=26
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.
geo...@googlecode.com
Comment #2 on issue 26 by jumpinja...@gmail.com: Better fresh checkout
build experience
http://code.google.com/p/georest/issues/detail?id=26
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.
geo...@googlecode.com
Comment #3 on issue 26 by ja...@jasonbirch.com: Better fresh checkout build
experience
http://code.google.com/p/georest/issues/detail?id=26
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.
geo...@googlecode.com
Comment #4 on issue 26 by jumpinja...@gmail.com: Better fresh checkout
build experience
http://code.google.com/p/georest/issues/detail?id=26
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.
geo...@googlecode.com
Comment #5 on issue 26 by jason.bi...@gmail.com: Better fresh checkout
build experience
http://code.google.com/p/georest/issues/detail?id=26
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.
geo...@googlecode.com
Comment #6 on issue 26 by jumpinja...@gmail.com: Better fresh checkout
build experience
http://code.google.com/p/georest/issues/detail?id=26
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.
geo...@googlecode.com
Comment #7 on issue 26 by jumpinja...@gmail.com: Better fresh checkout
build experience
http://code.google.com/p/georest/issues/detail?id=26
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.