[mapguide-internals] Re: OEM libraries was: 2.1.0 Final Windows Installer

[UV]

SOURCE COPIES
As with most other projects I have worked with, the used OSS libraries 
are simply copied to the
repository and build from there.
Although this prohibites the advantages of the OSS that somebody else 
might have fixed a bug in the meanwhile,
integration and debugging are largely simplified, thats why its a 
popular approach.

VERSION CHECKING
I fully agree that pointing an OSS build to the source server of the 
included library is very desirable,
however, to configure the build system to use a library from somewhere 
else is not so easy.
I think this would have to start with adding code to the DLL loader so 
it can be configured with permissible
library versions. This seems to be a paramount requirement for such 
endeavor.
When this is done we can consider a scheme to provide ready build OSS 
libraries in the repository.
Already some svn external links are used for some other sub projects, so 
this is one way to go.

EXTERNAL LINKS
This could be the starting point of a OEM library inclusion scheme based 
on header files and a set of ready built DLLs
included in the repository using external links. It should still be 
possible to rebuild the system from source to provide for a complete 
debug build.

However, to make this work is a mission which need to be well motivated.
I believe for most developers there are enough other issuess they 
consider more important than this.

CI FIRST
First of all I would strongly suggest to first get the continous 
integration (CI) system going before changing the build environment.
A previous attempt in this already exposed some of the issues which stem 
from little incompatibilities between project structures.
As MapGuide is multi-platform development changing the build that it 
works everywhere is hard.
Without a working CI system such a task is painful and inefficient.

CLASSIFICATION ATTEMPT
ACE             is probably better included as source due to its tight 
integration in the server and use of inline code
agg-2.4         could/should be external???
CppUnit-1.9 could/should be external???
CsMap         already external
DBXML       maybe better external as its big and a good example to use 
external to improve from outside help
DWFTK       could/should be external???
FDO             external and manually added to the build and installation
fusion            already external
php               could/should be external???
SQLite          ???
SWIGex        ???

So a build mechanism which lets the user choose between an external open 
source lib and the included source would be needed to make this useful.
Anyone interested?


Gabriele Monfardini wrote:
>> The 2.1 branch has been effectively frozen since June.  As far as I know,
>> the only submissions made to that branch have been specific to bug fixes
>> http://trac.osgeo.org/mapguide/log/branches/2.1/MgDev.
>> MgDev/trunk has always been the active development stream.
>> We only branch when we are getting close to a release.  And yes, trunk does get broken occasionally.
>>     
>
> Ok, thank you. I've missed the trunk version in the code browser-
>
>   
>> Most of the third party stack is not available on Windows so we include it in the source tree.
>>     
>
> I undestand your point.
> My question is: are software in the third part stack very customized
> for Mapguide or not?
>
> And if not (but I don't know, obviously), we're not really versioning
> that code. We only need the source code (maybe in a particular
> version) to be in a certain directory plus some small modifications.
>
> For example, let think from now on to one of this third part software, PHP.
>
> Would be viable to point to php 5.2 stable release and add a
> customized php.ini (as is done with the provider list in Oem/FDO)?
>
> This way we should benefit from bug fixing from PHP guys.
> If developers find that a certain release is no more compatible with
> mapguide, they can simply point to the last release that is
> compatible.
> "Users beware: PHP latest release (5.x.x) is not fully compatible with
> our code. While we're working on it, please use version 5.y.y instead
> to build mapguide".
>
> For lazy users, PHP code may remain as now, even in a
> "not-always-up-to-date" version, but it is important that I may opt to
> not download it and use current version.
>
> I think that maintaining "mapguide-PHP" up-to-date with PHP releases
> is overwhelming for you and, in the end, not the best way to use
> project resources.
> Testing new releases and report problems can be done by the community,
> and we should collaborate with PHP guys if we found regressions, bug
> or simply incompatibilities with our code in newer PHP versions.
>
> Maybe building the code from the source would be a little more
> complicated to setup than now.
> But I don't think that the average windows user Joe would build from
> the source code anyway, since the bar is already high if you're not a
> developer.
> Only developers would hit the small penalty (to have to download
> elsewhere PHP and apply some patches) but also to obtain the big
> advantages (not to have to maintain it).
>
> As a first step (since I know that proposing is easy, realizing
> require a lot of work) it would be useful just to keep track of exact
> version numbers used for all third party software, and if
> Mapguide-only modifications are, in your opinions and as a rule of
> thumb, small or big.
> This would enable we all to choose the easiest candidates to play with.
>
> I want to emphasize again that I'm not asking you to do the ugly work,
> but only discuss a way to enable users to contribute easily to the
> project,doing the ugly work :)
>
> Regards,
>
> Gabriele
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>
>