<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Trevor,<br>
<br>
Thanks for pointing this out. I was pondering on this issue already.<br>
I think the inconsistencies are coming from VS building into
bin/$(Config) and the need to bring the libs together.<br>
<br>
The solution to this can be simple as introducing a new target for the
build and dropping the default target bin\$(Config) for binaries<br>
We can keep the $(Config) part but instead of using the default target<br>
we rearrange the targets according to the new standards.<br>
(I.e we can have build the server into
MGDev/Server/Deploy/$(Config)/Bin)<br>
<br>
$(config)/bin<br>
$(config)/bin/FDO or $(config)/FDO????<br>
$(config)/Schema<br>
$(config)/Repository<br>
$(config)/....etc...<br>
<br>
In the moment the build server fails because the FDO SDK puts the
binaries in BIN but the build expects them in BIN\$(config)<br>
this is a good example of how to frustrate newbies. So the SDK actually
does not match what mapguide build expects.<br>
Maybe the best thing is to remove the $(Config) part of the path in the
mapguide build!?!?!?!<br>
Then we would just overwrite the existing files in MgDev/Oem/FDO/bin
and add an empty file to identify which config it is!<br>
Due to the identical names this is an option I believe. <br>
<br>
In the end the build server uses the solution files. Instead of the mix
of msbuild and scripts<br>
we could introduce an installation target for a postbuild.mak PostBuild
project, <br>
This could use either a default relative location or an environment
variable to deploy the results into the MapGuide build tree.<br>
<br>
Once this is established we realign the linux build to do the same. <br>
<br>
<br>
Trevor Wekel wrote:
<blockquote
cite="mid:D8305E7409B5DB46A9D6219E54E1CF1A2A583B1E9D@ADSK-NAMSG-01.MGDADSK.autodesk.com"
type="cite">
<pre wrap="">Hi UV,
There is a key difference between a build tree and an install tree that needs to be taken into consideration. For a build tree, you may have to build four different configurations - 32 bit debug, 32 bit release, 64 bit debug, and 64 bit release. For the install tree, you will likely only been installing either 32 bit release or 64 bit release.
The server and web extensions also need to be built into separate trees because IIS and Apache need virtual directories to work with and the ajax/fusion viewers need a specific directory layout to find everything they need.
I like the idea of having a common directory structure:
1. Copying a bunch of web files to some directory IIS or Apache likes is a hassle. I know Walt always used to give me trouble about the way the web extensions was laid out. It would be better if we could just point IIS or Apache at an appropriately laid out directory.
2. Co-developing MapGuide and Fdo functionality is freaking annoying. Build Fdo, build -c install Fdo, copy Fdo dlls and headers to where MapGuide wants them, then build MapGuide. Yuck.
Can anyone think of other requirements on a common build/install directory structure for MapGuide (server/web) and Fdo?
The following structure isn't right yet but it does introduce some symmetry between components and separates out the different build flavours. The Web bit is definitely not right from a symmetry argument. All the separate Bin directories make this structure a no-go without setting path variables. And the question what about Linux? comes to mind.
Release
CSMap
11g
Bin
Lib
Inc
Obj
Fdo
com
Bin
Inc
Obj
[subprojects]
Lib
Platform (shared dlls for Server/Web)
Bin
Inc
Lib
Obj
[subprojects]
Server
Bin
Lib
Obj
[subprojects]
Logs
Packages
Repositories
Resources
Schema
Wfs
Wms
Web
Apache2 (if built)
Php
www
WebStudio
???
Debug
Fdo
Platform
Server
Web
WebStudio
Release64
Debug64
-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:mapguide-internals-bounces@lists.osgeo.org">mapguide-internals-bounces@lists.osgeo.org</a> [<a class="moz-txt-link-freetext" href="mailto:mapguide-internals-bounces@lists.osgeo.org">mailto:mapguide-internals-bounces@lists.osgeo.org</a>] On Behalf Of UV
Sent: Thursday, April 16, 2009 4:41 PM
To: MapGuide Internals Mail List
Subject: Re: [mapguide-internals] build script confusion RFC62???
thanks, thats the way the decision can be made.
But first people have to agree what needs to be done. In the current
situation there are little inconsistencies which make our life hard.
I am sure the core team has their systems set up long enough that they
dont know about these things anymore.
I do because I struggled hard to get the build running in the first place.
Trying to get the build server to do this now is pointing out the exact
details of where the problems are.
Tom Fukushima wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi UV,
The process for RFCs is described on this page: <a class="moz-txt-link-freetext" href="http://mapguide.osgeo.org/psc.html">http://mapguide.osgeo.org/psc.html</a>.
Is this what you're looking for?
Cheers
Tom
-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:mapguide-internals-bounces@lists.osgeo.org">mapguide-internals-bounces@lists.osgeo.org</a> [<a class="moz-txt-link-freetext" href="mailto:mapguide-internals-bounces@lists.osgeo.org">mailto:mapguide-internals-bounces@lists.osgeo.org</a>] On Behalf Of UV
Sent: Wednesday, April 15, 2009 7:38 PM
To: MapGuide Internals Mail List
Subject: Re: [mapguide-internals] build script confusion RFC62???
Is there a way to initiate as decision process?
or do we have to give up on the automated build because no decision can
be made regarding the result of the build?
This is needed before any changes can be made.
Its not so much todo except to agree on a useful structure for the build
/ deploy process.
In the moment we have a windows installer, a postbuild.mak and a
build.bat plus Linux makefiles all doing similar but slightly different
things.
I think this is a unique opportunity to align some of the
inconsistencies in the build process of mapguide and
improve the experience for future contributions.
Thats exactly whats CI is for..... making sure such inconcistencies will
never happen again.
_______________________________________________
mapguide-internals mailing list
<a class="moz-txt-link-abbreviated" href="mailto:mapguide-internals@lists.osgeo.org">mapguide-internals@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/mapguide-internals">http://lists.osgeo.org/mailman/listinfo/mapguide-internals</a>
_______________________________________________
mapguide-internals mailing list
<a class="moz-txt-link-abbreviated" href="mailto:mapguide-internals@lists.osgeo.org">mapguide-internals@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/mapguide-internals">http://lists.osgeo.org/mailman/listinfo/mapguide-internals</a>
</pre>
</blockquote>
<pre wrap=""><!---->
_______________________________________________
mapguide-internals mailing list
<a class="moz-txt-link-abbreviated" href="mailto:mapguide-internals@lists.osgeo.org">mapguide-internals@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/mapguide-internals">http://lists.osgeo.org/mailman/listinfo/mapguide-internals</a>
_______________________________________________
fdo-internals mailing list
<a class="moz-txt-link-abbreviated" href="mailto:fdo-internals@lists.osgeo.org">fdo-internals@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/fdo-internals">http://lists.osgeo.org/mailman/listinfo/fdo-internals</a>
</pre>
</blockquote>
<br>
</body>
</html>