MapGuide RFC 62 - Defining consistent Structures for Mapguide and FDO Releases and Builds
This page contains an change request (RFC) for the MapGuide Open Source project. More MapGuide RFCs can be found on the RFCs page.
Status
| RFC Template Version | (1.0) |
| Submission Date | (09.04.2009) |
| Last Modified | (UV Wildner) Timestamp |
| Author | (UV Wildner) |
| RFC Status | (draft) |
| Implementation Status | (discussion needed) |
| Proposed Milestone | (2.1) |
| Assigned PSC guide(s) | (when determined) |
| Voting History | (vote date) |
| +1 | |
| +0 | |
| -0 | |
| -1 | |
| no vote |
Overview
The build processs for Mapguide and FDO are not fully aligned. Similarly the structure of released packages sometimes differ from the ones created by the build. Those structures need to be aligned for the build server to create builds which can be installed and tested within the build server.
Motivation
Currently there is an inconsistency between the output of the FDO and the released FDO SDK. That means if you try to build Mapguide using the FDO SDK the postbuild.mak fails. Similarly, the directory structure created by the released Mapguide Installer is different from the one created by the build. Those differences cause hard to resolve discrepancies in the setup and fail the build process.
Proposed Solution
Those structures need to be defined in a reference spec. Once those structures are defined in a specification the current places need to be aligned to it:
- on the build server
- in the new WIX installers
- in the makefiles
- Visual Studio post build scripts
- release packages
This applies to FDO as much as for Mapguide. I suggest to build FDO on the very same build server as this provides a reference for the dependency situation which is a bit vague in the main trunk. If FDO is included in the build server the build scripts ARE THE REFERENCE as otherwise the build simply fails. Similarly the build server creates the packages to be released according to the same spec.
Implications
The build, and install scripts and tools need to be aligned. As a result the system can be build by an automated build server which can also create the installer packages and distributions.
Test Plan
Successful build server builds.
Funding/Resources
Frustrated developers needing to sort this out once and for all.
closed Issues
NONE
open Issues
Defining the Structures of
Server Directory
SupportDirs are Logs, Repositories, Resources, Schema, Temp, wfs, wms
Currently there are 3 versions:
- SupportDirs as well as FDO Inside the BIN/$(config) dir (which is the $(OutDir) of Visual Studio and Postbuild.mak writes in this)
./bin/$(config) ./bin/$(config)/fdo ./bin/$(config)/$(supportdirs)
- SupportDirs one level up with FDO Inside Bin dir (no $config anymore) result of 2.0.2 Installer
./bin ./bin/fdo ./$(supportdirs)
- SupportDirs one level with FDO next to Bin Dir (new WIX Installer structure)
./bin ./fdo ./$(supportdirs)
FDO SDK Directory
bin,docs, inc, lib
- Bin/$(Config) where Postbuild.mak expects the libaries
./bin/debug ./bin/release ./docs ./inc ./lib
- Bin (no configdir) (fdosdk and installer)
./bin ./docs ./inc ./lib
As the FDO libraries have the same name for both debug and release versions they can be easily swapped. However, we need to define a way how to differentiate them so a build process or installer or developer can decide what to do.
Suggestions
- We need a build area to build things into. Just the servercore outdir is not a good place. Lets call this BUILDTARGET.
with the right paths we can have a buildTarget for the build process which has the following structure:
./release ./debug ./FDO ./docs ./inc ./lib
- The postbuild.mak needs to be adapted to recreate the structure that results from this dicussion .... this implies a change to the default serverconfig.ini.
- The debug configs of the servercore.vcproj needs to point to the BUILDTARGET/$(config) directory
- The FDO bindir should be marked with a simple file in the build directory (release/debug). This is easy to do.... intuitive and can be understood by any build script (using a simple file existence test)
- By including the fdo with an external link we have a defined location and can create default installations for the FDO builds
(here we need to discuss how far we want to support the different versions) so if you say build it ends up in the right place. If thats not desired for any reason we create an additional build config(target) for the FDO build called Mapguide debug, mapguide release
