[fdo-internals] Re: build script confusion RFC62???

[UV]

In mapguide RFC62 I pointed out the 3 different scenarios for arranging 
the server directory.

All different ways to create them can be adapted to whatever people 
think is correct.
I am just trying to make sure its always the same because otherwise we 
have a built-in trap for people trying to build it the first time.
In particular the build output of the development system should have the 
same structure as the released installer output
so the devel&test environment can be easily reset to a defined state.

Anyway its only a simple decision and requires just a few small changes 
in the various build paths.
I could have done all this in a fraction of the time typing these mails 
trying to explain the issue, but this needs full repository access and we
should also include the FDO build in this action so we can build the lot 
on the build server.

Like many documentation issues this is a  situation where its difficult 
to motivate people that are past the learning curve to ease the learning 
curve for the ones before it. Luckily in this case the build server 
which requires a commitment to one way or the other is of use for everyone.

I also ran into the limits of my ability to contribute to the build 
process. When I cannot change things in the repository I cannot tune the 
build process as it reads from the repository. Doing this with patches 
is a waste of my time. Maybe I can get at least access to the mirror rep 
on the build server Trevor?

Jason Birch wrote:
> Hi UV,
>
> A MapGuide RFC can't be used to modify the FDO build structure, that needs to be dealt with in the FDO project.  Yes, there is a lot of overlap between the projects, but they are autonomous.  While I am in favour of accommodating an FDO CI process on the MapGuide build server, I think that we should focus on getting the MapGuide CI working first.
>
> I'm not sure that I see the value in making the default installer directory structure mirror the build output's directory structure.  Having release / debug / x86 / x64 in the binaries path doesn't really make a lot of sense to the end user.  I wonder if we can accomplish something similar for non-release builds on the CI machine by passing a public property to msiexec to install the bin files to a different location?
>
> Jason
>
> -----Original Message-----
> From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of UV
> Sent: April-15-09 6: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
> mapguide-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>
>