MapGuide open source builds - Linux & Cmake

[zspitzer]

Just breaking the Cmake stuff out into a seperate thread

Based on the feedback from the AD developers about sticking with the VS
build system on Windows, what do people think about the Cmake option on linux

>From the sound of things if we go ahead with this, we are going to
keep the existing
build system for windows and adopt cmake for any other platforms

Can we add Helio's stuff to the tree and run with two build systems?

Helio, the existing full build with all the embedded thirdparty stuff
works currently?

If it does and we don't have to worry about the issues like the db 4.2
you mentioned
the 2.1 release could be a good opportunity to test this out as I
assume quite a
few people are going to be trying to compile 2.1 on linux

I am prepared to be a crash test dummy on this...

z


On Thu, Oct 9, 2008 at 3:58 AM, Helio Chissini de Castro <[hidden email]> wrote:

> On Quarta 08 Outubro 2008 13:22:26 Traian Stanev wrote:
>> Yes, I did a 64 bit FDO build using externally installed dependent third
>> party libraries last week on Ubuntu, and it worked out pretty well. I did
>> not compile all providers though, so I can't speak for all the
>> dependencies, just xerces/xalan and the like.
>>
>> Traian
>>
>
> Hi guys, i'm on a quick trio on US and Zac ping me about the discussion.
> For 64 bits, i already have cake build working with most of the third party
> dependencies sorted.
>
> I have mapguide too, with some small issue, which is DB 4.2
> Maptguide relies in DB 4.2, most of distros have DB 4.5 or 4.6 apache build (
> apr things ), which lead me to try compile mapguide with a recent Db
> The problem is even been API compatible, db segfaults everytime in the
> database creation, and i had no time to solve the issue.
> To fix my problem i recompiled my apache rpm with exactly same db mapguide
> have.
>
> As Jason commented about the frustration of the whole RFC, to not kept too
> much out of sync, i did rpm version for current fdo, and mapguide, but only 32
> bits, as pristine as possible.
>
> As soon i back from US i can answer other questions with more time
>
> []'s
>
>
> --
> Helio Chissini de Castro
> KDE Project
> Brasil and South America Primary Contact
> _______________________________________________
> mapguide-internals mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>

--
Zac Spitzer -
http://zacster.blogspot.com (My Blog)
[phone]
_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

[Frank Warmerdam]

Zac Spitzer wrote:

> Just breaking the Cmake stuff out into a seperate thread
>
> Based on the feedback from the AD developers about sticking with the VS
> build system on Windows, what do people think about the Cmake option on linux
>
>>From the sound of things if we go ahead with this, we are going to
> keep the existing
> build system for windows and adopt cmake for any other platforms
>
> Can we add Helio's stuff to the tree and run with two build systems?
>
> Helio, the existing full build with all the embedded thirdparty stuff
> works currently?
>
> If it does and we don't have to worry about the issues like the db 4.2
> you mentioned
> the 2.1 release could be a good opportunity to test this out as I
> assume quite a
> few people are going to be trying to compile 2.1 on linux
>
> I am prepared to be a crash test dummy on this...

Zac,

I don't feel like I ever really understood what cmake would be accomplishing
for us if we only used it on Unix.  I'm concerned we are substituting a
build system we know nothing about for a build system we at least sort of
know.  Perhaps the main benefits of Helio's work are getting away from the
dependency on our own copy of third party libraries, or stuff like that.
If that is the case, then why not pursue that more directly?

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent

_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

[zspitzer]

Hi Frank,

I share your concerns and I saw you comments about what happened with GDAL..

from my (limited) understanding, using Cmake gives us a much simple
build process
instead of the multi-step autoconf etc and it the work which Helio has done
also addresses the issues of producing installable packages for linux,
defined dependencies
and the potential to remove some of the older third party stuff from the tree

I'm probably repeating myself there.... :)

Can someone who's accross both the current linux build system and
familiar with Cmake
care to comment?

z



On Thu, Oct 9, 2008 at 2:12 PM, Frank Warmerdam <[hidden email]> wrote:

> Zac Spitzer wrote:
>>
>> Just breaking the Cmake stuff out into a seperate thread
>>
>> Based on the feedback from the AD developers about sticking with the VS
>> build system on Windows, what do people think about the Cmake option on
>> linux
>>
>>> From the sound of things if we go ahead with this, we are going to
>>
>> keep the existing
>> build system for windows and adopt cmake for any other platforms
>>
>> Can we add Helio's stuff to the tree and run with two build systems?
>>
>> Helio, the existing full build with all the embedded thirdparty stuff
>> works currently?
>>
>> If it does and we don't have to worry about the issues like the db 4.2
>> you mentioned
>> the 2.1 release could be a good opportunity to test this out as I
>> assume quite a
>> few people are going to be trying to compile 2.1 on linux
>>
>> I am prepared to be a crash test dummy on this...
>
> Zac,
>
> I don't feel like I ever really understood what cmake would be accomplishing
> for us if we only used it on Unix.  I'm concerned we are substituting a
> build system we know nothing about for a build system we at least sort of
> know.  Perhaps the main benefits of Helio's work are getting away from the
> dependency on our own copy of third party libraries, or stuff like that.
> If that is the case, then why not pursue that more directly?
>
> Best regards,
> --
> ---------------------------------------+--------------------------------------
> I set the clouds in motion - turn up   | Frank Warmerdam,
> [hidden email]
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush    | Geospatial Programmer for Rent
>
> _______________________________________________
> mapguide-internals mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>

--
Zac Spitzer -
http://zacster.blogspot.com (My Blog)
[phone]
_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

[Jason Birch]

I can see your point Frank, but from my layman's perspective cmake is a lot more approachable than the existing build system, and by default it seems to do sane things like building into a different tree than source, etc, etc.  I also remember someone saying that it was considerably faster?
 
To look at it another way:  Helio has already done the work to create a cmake-based installer that provides much better Linux support, presumably because it was easier for him to do this with cmake.  Linux support is an extremely weak point for MapGuide, and the primary developers only have a vested interest in supporting RHEL/CentOS builds.  Unless someone else has time/energy to duplicate Helio's efforts using the existing build chain, I'm in favour of moving to cmake for the MapGuide Linux build procedure.
 
As far as Windows builds go... Unlike other open source tools, MapGuide's primary development is done in Windows.  It doesn't make sense to replace the manually maintained VS-based projects with automatically generated ones when most of the developers spend the majority of their time in VS anyway.
 
Jason
 
________________________________

From: Frank Warmerdam
Subject: Re: [mapguide-internals] MapGuide open source builds - Linux & Cmake

I don't feel like I ever really understood what cmake would be accomplishing
for us if we only used it on Unix.  I'm concerned we are substituting a
build system we know nothing about for a build system we at least sort of
know.  Perhaps the main benefits of Helio's work are getting away from the
dependency on our own copy of third party libraries, or stuff like that.
If that is the case, then why not pursue that more directly?

_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

[Jackie Ng]

Building MapGuide in Linux is just painful right now, the last time I was
able to build MapGuide without major issues was when the trunk was in
pre-2.0 revision.

Even then, you had to get all the build steps correct without fail, or bad
things may (and do) happen.

I'm all for improvements to the build system on the linux side (at least).

- Jackie


zspitzer wrote:

>
> Just breaking the Cmake stuff out into a seperate thread
>
> Based on the feedback from the AD developers about sticking with the VS
> build system on Windows, what do people think about the Cmake option on
> linux
>
>>From the sound of things if we go ahead with this, we are going to
> keep the existing
> build system for windows and adopt cmake for any other platforms
>
> Can we add Helio's stuff to the tree and run with two build systems?
>
> Helio, the existing full build with all the embedded thirdparty stuff
> works currently?
>
> If it does and we don't have to worry about the issues like the db 4.2
> you mentioned
> the 2.1 release could be a good opportunity to test this out as I
> assume quite a
> few people are going to be trying to compile 2.1 on linux
>
> I am prepared to be a crash test dummy on this...
>
> z
>
>
> On Thu, Oct 9, 2008 at 3:58 AM, Helio Chissini de Castro <[hidden email]>
> wrote:
>> On Quarta 08 Outubro 2008 13:22:26 Traian Stanev wrote:
>>> Yes, I did a 64 bit FDO build using externally installed dependent third
>>> party libraries last week on Ubuntu, and it worked out pretty well. I
>>> did
>>> not compile all providers though, so I can't speak for all the
>>> dependencies, just xerces/xalan and the like.
>>>
>>> Traian
>>>
>>
>> Hi guys, i'm on a quick trio on US and Zac ping me about the discussion.
>> For 64 bits, i already have cake build working with most of the third
>> party
>> dependencies sorted.
>>
>> I have mapguide too, with some small issue, which is DB 4.2
>> Maptguide relies in DB 4.2, most of distros have DB 4.5 or 4.6 apache
>> build (
>> apr things ), which lead me to try compile mapguide with a recent Db
>> The problem is even been API compatible, db segfaults everytime in the
>> database creation, and i had no time to solve the issue.
>> To fix my problem i recompiled my apache rpm with exactly same db
>> mapguide
>> have.
>>
>> As Jason commented about the frustration of the whole RFC, to not kept
>> too
>> much out of sync, i did rpm version for current fdo, and mapguide, but
>> only 32
>> bits, as pristine as possible.
>>
>> As soon i back from US i can answer other questions with more time
>>
>> []'s
>>
>>
>> --
>> Helio Chissini de Castro
>> KDE Project
>> Brasil and South America Primary Contact
>> _______________________________________________
>> mapguide-internals mailing list
>> [hidden email]
>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>>
>
>
>
> --
> Zac Spitzer -
> http://zacster.blogspot.com (My Blog)
> [phone]
> _______________________________________________
> mapguide-internals mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>
>

--
View this message in context: http://n2.nabble.com/MapGuide-open-source-builds---Linux---Cmake-tp1308409p1308715.html
Sent from the MapGuide Internals mailing list archive at Nabble.com.

_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

[Traian Stanev]

For what it's worth, I tried to use cmake last night to set up a Linux build for the SQLite provider. I wanted to see what the big deal was about cmake. Now I know -- it doesn't suck. I see no problem as using cmake for the Linux build, or even only as an optional build system alongside automake -- the cmake files are just some more text files that would be sitting alongside the automake files.


Traian

> -----Original Message-----
> From: [hidden email] [mailto:mapguide-
> [hidden email]] On Behalf Of Jason Birch
> Sent: Wednesday, October 08, 2008 11:37 PM
> To: MapGuide Internals Mail List; MapGuide Internals Mail List
> Subject: RE: [mapguide-internals] MapGuide open source builds - Linux &
> Cmake
>
> I can see your point Frank, but from my layman's perspective cmake is a
> lot more approachable than the existing build system, and by default it
> seems to do sane things like building into a different tree than source,
> etc, etc.  I also remember someone saying that it was considerably
> faster?
>
> To look at it another way:  Helio has already done the work to create a
> cmake-based installer that provides much better Linux support,
> presumably because it was easier for him to do this with cmake.  Linux
> support is an extremely weak point for MapGuide, and the primary
> developers only have a vested interest in supporting RHEL/CentOS builds.
> Unless someone else has time/energy to duplicate Helio's efforts using
> the existing build chain, I'm in favour of moving to cmake for the
> MapGuide Linux build procedure.
>
> As far as Windows builds go... Unlike other open source tools,
> MapGuide's primary development is done in Windows.  It doesn't make
> sense to replace the manually maintained VS-based projects with
> automatically generated ones when most of the developers spend the
> majority of their time in VS anyway.
>
> Jason
>
> ________________________________
>
> From: Frank Warmerdam
> Subject: Re: [mapguide-internals] MapGuide open source builds - Linux &
> Cmake
>
> I don't feel like I ever really understood what cmake would be
> accomplishing
> for us if we only used it on Unix.  I'm concerned we are substituting a
> build system we know nothing about for a build system we at least sort
> of
> know.  Perhaps the main benefits of Helio's work are getting away from
> the
> dependency on our own copy of third party libraries, or stuff like that.
> If that is the case, then why not pursue that more directly?
>
> _______________________________________________
> mapguide-internals mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals

_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

[zspitzer]

thanks for taking the time to try it out Traian,

i liked the 6 minute commit comment :)

On Fri, Oct 10, 2008 at 12:38 AM, Traian Stanev
<[hidden email]> wrote:

>
> For what it's worth, I tried to use cmake last night to set up a Linux build for the SQLite provider. I wanted to see what the big deal was about cmake. Now I know -- it doesn't suck. I see no problem as using cmake for the Linux build, or even only as an optional build system alongside automake -- the cmake files are just some more text files that would be sitting alongside the automake files.
>
>
> Traian
>
>
>> -----Original Message-----
>> From: [hidden email] [mailto:mapguide-
>> [hidden email]] On Behalf Of Jason Birch
>> Sent: Wednesday, October 08, 2008 11:37 PM
>> To: MapGuide Internals Mail List; MapGuide Internals Mail List
>> Subject: RE: [mapguide-internals] MapGuide open source builds - Linux &
>> Cmake
>>
>> I can see your point Frank, but from my layman's perspective cmake is a
>> lot more approachable than the existing build system, and by default it
>> seems to do sane things like building into a different tree than source,
>> etc, etc.  I also remember someone saying that it was considerably
>> faster?
>>
>> To look at it another way:  Helio has already done the work to create a
>> cmake-based installer that provides much better Linux support,
>> presumably because it was easier for him to do this with cmake.  Linux
>> support is an extremely weak point for MapGuide, and the primary
>> developers only have a vested interest in supporting RHEL/CentOS builds.
>> Unless someone else has time/energy to duplicate Helio's efforts using
>> the existing build chain, I'm in favour of moving to cmake for the
>> MapGuide Linux build procedure.
>>
>> As far as Windows builds go... Unlike other open source tools,
>> MapGuide's primary development is done in Windows.  It doesn't make
>> sense to replace the manually maintained VS-based projects with
>> automatically generated ones when most of the developers spend the
>> majority of their time in VS anyway.
>>
>> Jason
>>
>> ________________________________
>>
>> From: Frank Warmerdam
>> Subject: Re: [mapguide-internals] MapGuide open source builds - Linux &
>> Cmake
>>
>> I don't feel like I ever really understood what cmake would be
>> accomplishing
>> for us if we only used it on Unix.  I'm concerned we are substituting a
>> build system we know nothing about for a build system we at least sort
>> of
>> know.  Perhaps the main benefits of Helio's work are getting away from
>> the
>> dependency on our own copy of third party libraries, or stuff like that.
>> If that is the case, then why not pursue that more directly?
>>
>> _______________________________________________
>> mapguide-internals mailing list
>> [hidden email]
>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
> _______________________________________________
> mapguide-internals mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>

--
Zac Spitzer -
http://zacster.blogspot.com (My Blog)
[phone]
_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

[Frank Warmerdam]

Traian Stanev wrote:
> For what it's worth, I tried to use cmake last night to set up a Linux build
> for the SQLite provider. I wanted to see what the big deal was about cmake.
> Now I know -- it doesn't suck. I see no problem as using cmake for the Linux
> build, or even only as an optional build system alongside automake -- the
> cmake files are just some more text files that would be sitting alongside
> the automake files.

Folks,

Well, while I'm still a bit uncertain (I have had a very confusing time with
cmake in the QGIS project) I think it could be quite viable as long as there
are long term committed developers like Traian willing to support it.

If we do move to cmake I would encourage flushing all the automake/autoconf
stuff so that we fully get the advantage of the cmake simplicity.  (well
perhaps after a modest transitional period).

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent

_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

[Traian Stanev]

> -----Original Message-----
> From: [hidden email] [mailto:mapguide-
> [hidden email]] On Behalf Of Frank Warmerdam
> (External)
> Sent: Thursday, October 09, 2008 10:28 AM
> To: MapGuide Internals Mail List
> Subject: Re: [mapguide-internals] MapGuide open source builds - Linux &
> Cmake
>
> Traian Stanev wrote:
> > For what it's worth, I tried to use cmake last night to set up a
> Linux build
> > for the SQLite provider. I wanted to see what the big deal was about
> cmake.
> > Now I know -- it doesn't suck. I see no problem as using cmake for
> the Linux
> > build, or even only as an optional build system alongside automake --
> the
> > cmake files are just some more text files that would be sitting
> alongside
> > the automake files.
>
> Folks,
>
> Well, while I'm still a bit uncertain (I have had a very confusing time
> with
> cmake in the QGIS project) I think it could be quite viable as long as
> there
> are long term committed developers like Traian willing to support it.
>
> If we do move to cmake I would encourage flushing all the
> automake/autoconf
> stuff so that we fully get the advantage of the cmake simplicity.
> (well
> perhaps after a modest transitional period).
>
> Best regards,
> --
> ---------------------------------------+-------------------------------
> -------
> I set the clouds in motion - turn up   | Frank Warmerdam,
> [hidden email]
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush    | Geospatial Programmer for Rent
>
> _______________________________________________
> mapguide-internals mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals

Hi Frank,

I'm only adding another data point to the discussion, I know you have the opposite opinion. Setting up the cmake files was easier to me than autotools, because I could mentally map the items in the CMakeLists.txt file to items in the project properties of Visual Studio.

I agree with what you said yesterday as well -- we can make the current build link to libraries that are already installed on the system. In fact I think this should have higher priority than switching the build system to cmake, because it would remove the need to compile all the third party components, which has been a big source of compile errors for people who compile on platforms other than RedHat. It would also speed up said build enormously, and would make sure third party components are automatically up to date with the latest bug fixes.

The existing Linux builds systems for both MapGuide and FDO are too opaque and complex and error prone to be tenable in the long run. Simply put, they hurt adoption.

Traian



_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

[Gabriele Monfardini]

> I agree with what you said yesterday as well -- we can make the current build link to libraries that are already installed on the system. In fact I think this should have higher priority than switching the build system to cmake, because it would remove the need to compile all the third party components, which has been a big source of compile errors for people who compile on platforms other than RedHat.

I completely agree. One of the most confusing part is to have to
compile libraries that are already on the system, usually in an
outdated version, and having to play around with path and env vars
just to use this older version. Very error prone.
In an ideal situation build syetm would complain about some missing
dependencies that should be installed using distribution repositories.
In this way third part component are always up-to-date, installed in
known paths and all tricky distribution-dependendent issues are
automatically risolved by package mantainer. This is one of the big
plus of having a central software repository, we should exploit it.

This, also IMHO, should have the highest priority if we want to favor
the adoption of Mapguide also in Linux environments.

By the way, I've compiled QGIS using cmake several times. I am by no
means a cmake expert but all worked out very smoothly. Feedback to the
user is explicative (and colorful), all dependecies are handled
correctly and, most of the times all work out-of-the-box without any
need to tweak any parameter. And this in many modern Linux
distribution.
I would like to contribute with the experience of a big and
multiplatform project that has chosen CMake over autotools
(http://lwn.net/Articles/188693/).

Gabriele
_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

[zspitzer]

That was an interesting article Gabriele, if a major project like KDE
is using CMake
and it's as easy Traian found, plus it already works, lets put together a RFC.

If it only requires some additional files which can co-exist with the
current build
system (for now), lets get Helio's work into the source tree and give it a go

On Fri, Oct 10, 2008 at 6:41 AM, Gabriele Monfardini
<[hidden email]> wrote:

>> I agree with what you said yesterday as well -- we can make the current build link to libraries that are already installed on the system. In fact I think this should have higher priority than switching the build system to cmake, because it would remove the need to compile all the third party components, which has been a big source of compile errors for people who compile on platforms other than RedHat.
>
> I completely agree. One of the most confusing part is to have to
> compile libraries that are already on the system, usually in an
> outdated version, and having to play around with path and env vars
> just to use this older version. Very error prone.
> In an ideal situation build syetm would complain about some missing
> dependencies that should be installed using distribution repositories.
> In this way third part component are always up-to-date, installed in
> known paths and all tricky distribution-dependendent issues are
> automatically risolved by package mantainer. This is one of the big
> plus of having a central software repository, we should exploit it.
>
> This, also IMHO, should have the highest priority if we want to favor
> the adoption of Mapguide also in Linux environments.
>
> By the way, I've compiled QGIS using cmake several times. I am by no
> means a cmake expert but all worked out very smoothly. Feedback to the
> user is explicative (and colorful), all dependecies are handled
> correctly and, most of the times all work out-of-the-box without any
> need to tweak any parameter. And this in many modern Linux
> distribution.
> I would like to contribute with the experience of a big and
> multiplatform project that has chosen CMake over autotools
> (http://lwn.net/Articles/188693/).
>
> Gabriele
> _______________________________________________
> mapguide-internals mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>

--
Zac Spitzer -
http://zacster.blogspot.com (My Blog)
[phone]
_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

[Helio Chissini de Castro]

On Quinta 09 Outubro 2008 22:58:47 Zac Spitzer wrote:

> That was an interesting article Gabriele, if a major project like KDE
> is using CMake
> and it's as easy Traian found, plus it already works, lets put together a
> RFC.
>
> If it only requires some additional files which can co-exist with the
> current build
> system (for now), lets get Helio's work into the source tree and give it a
> go
>
> On Fri, Oct 10, 2008 at 6:41 AM, Gabriele Monfardini
>

Ok, did my appointments here and can give more input.. or.. no.. better :-)
On Saturday or Sunday i will make available my current almost ready cmakefied
mapguide, with:
- Tests for external dependencies ( as Gabriele pointed )
- Internal dir dependencies to make possible a paralel building wihtou
breaking the chain ( btw, at Mandriva labs i compiled with a make -j 30 in our
icecream distributed compiler environment ).
- so'naming libraries, to have proper .so.<VERSION>
- All necessary ThirdParty tools removed except the required ones, like gd.

Some tidbits
- Some patches are needed to compile against 64, but minor ones
- Now i have FDO been tested against my cmake version. I will change the test
to match a auto*tools current installation
- Some different steps than the current instructions is needed to setup
external apache. I will detail that ones.

I just not push it today because i want deliver it with trunk, my current one
is 2.0.0 only and is better present a up-to-date experience.

If someone become curious about the compiler cluster, is all open source and
free and if you are like me have more than one machine in network, worth a
lot: http://en.opensuse.org/Icecream

[]'s

--
Helio Chissini de Castro
KDE Project
Brasil and South America Primary Contact
_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

[Jackie Ng]

Now that its open season on MapGuide sandboxes, we should get a cmake-based MapGuide sandbox up and going.

- Jackie

zspitzer wrote:

Just breaking the Cmake stuff out into a seperate thread

Based on the feedback from the AD developers about sticking with the VS
build system on Windows, what do people think about the Cmake option on linux

>From the sound of things if we go ahead with this, we are going to
keep the existing
build system for windows and adopt cmake for any other platforms

Can we add Helio's stuff to the tree and run with two build systems?

Helio, the existing full build with all the embedded thirdparty stuff
works currently?

If it does and we don't have to worry about the issues like the db 4.2
you mentioned
the 2.1 release could be a good opportunity to test this out as I
assume quite a
few people are going to be trying to compile 2.1 on linux

I am prepared to be a crash test dummy on this...

z


On Thu, Oct 9, 2008 at 3:58 AM, Helio Chissini de Castro <[e-mail]> wrote:
> On Quarta 08 Outubro 2008 13:22:26 Traian Stanev wrote:
>> Yes, I did a 64 bit FDO build using externally installed dependent third
>> party libraries last week on Ubuntu, and it worked out pretty well. I did
>> not compile all providers though, so I can't speak for all the
>> dependencies, just xerces/xalan and the like.
>>
>> Traian
>>
>
> Hi guys, i'm on a quick trio on US and Zac ping me about the discussion.
> For 64 bits, i already have cake build working with most of the third party
> dependencies sorted.
>
> I have mapguide too, with some small issue, which is DB 4.2
> Maptguide relies in DB 4.2, most of distros have DB 4.5 or 4.6 apache build (
> apr things ), which lead me to try compile mapguide with a recent Db
> The problem is even been API compatible, db segfaults everytime in the
> database creation, and i had no time to solve the issue.
> To fix my problem i recompiled my apache rpm with exactly same db mapguide
> have.
>
> As Jason commented about the frustration of the whole RFC, to not kept too
> much out of sync, i did rpm version for current fdo, and mapguide, but only 32
> bits, as pristine as possible.
>
> As soon i back from US i can answer other questions with more time
>
> []'s
>
>
> --
> Helio Chissini de Castro
> KDE Project
> Brasil and South America Primary Contact
> _______________________________________________
> mapguide-internals mailing list
> [e-mail]
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>



--
Zac Spitzer -
http://zacster.blogspot.com (My Blog)
[phone]
_______________________________________________
mapguide-internals mailing list
[e-mail]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

[Jason Birch]

I'd be strongly in favour of this. The fdo work has been really cool...

----- Original Message -----
From: [hidden email] <[hidden email]>
To: [hidden email] <[hidden email]>
Sent: Wed Jul 29 05:57:05 2009
Subject: Re: [mapguide-internals] MapGuide open source builds - Linux & Cmake


Now that its open season on MapGuide sandboxes, we should get a cmake-based
MapGuide sandbox up and going.

- Jackie


zspitzer wrote:

>
> Just breaking the Cmake stuff out into a seperate thread
>
> Based on the feedback from the AD developers about sticking with the VS
> build system on Windows, what do people think about the Cmake option on
> linux
>
>>From the sound of things if we go ahead with this, we are going to
> keep the existing
> build system for windows and adopt cmake for any other platforms
>
> Can we add Helio's stuff to the tree and run with two build systems?
>
> Helio, the existing full build with all the embedded thirdparty stuff
> works currently?
>
> If it does and we don't have to worry about the issues like the db 4.2
> you mentioned
> the 2.1 release could be a good opportunity to test this out as I
> assume quite a
> few people are going to be trying to compile 2.1 on linux
>
> I am prepared to be a crash test dummy on this...
>
> z
>
>
> On Thu, Oct 9, 2008 at 3:58 AM, Helio Chissini de Castro <[hidden email]>
> wrote:
>> On Quarta 08 Outubro 2008 13:22:26 Traian Stanev wrote:
>>> Yes, I did a 64 bit FDO build using externally installed dependent third
>>> party libraries last week on Ubuntu, and it worked out pretty well. I
>>> did
>>> not compile all providers though, so I can't speak for all the
>>> dependencies, just xerces/xalan and the like.
>>>
>>> Traian
>>>
>>
>> Hi guys, i'm on a quick trio on US and Zac ping me about the discussion.
>> For 64 bits, i already have cake build working with most of the third
>> party
>> dependencies sorted.
>>
>> I have mapguide too, with some small issue, which is DB 4.2
>> Maptguide relies in DB 4.2, most of distros have DB 4.5 or 4.6 apache
>> build (
>> apr things ), which lead me to try compile mapguide with a recent Db
>> The problem is even been API compatible, db segfaults everytime in the
>> database creation, and i had no time to solve the issue.
>> To fix my problem i recompiled my apache rpm with exactly same db
>> mapguide
>> have.
>>
>> As Jason commented about the frustration of the whole RFC, to not kept
>> too
>> much out of sync, i did rpm version for current fdo, and mapguide, but
>> only 32
>> bits, as pristine as possible.
>>
>> As soon i back from US i can answer other questions with more time
>>
>> []'s
>>
>>
>> --
>> Helio Chissini de Castro
>> KDE Project
>> Brasil and South America Primary Contact
>> _______________________________________________
>> mapguide-internals mailing list
>> [hidden email]
>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>>
>
>
>
> --
> Zac Spitzer -
> http://zacster.blogspot.com (My Blog)
> [phone]
> _______________________________________________
> mapguide-internals mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>
>

--
View this message in context: http://n2.nabble.com/MapGuide-open-source-builds---Linux---Cmake-tp1822143p3349528.html
Sent from the MapGuide Internals mailing list archive at Nabble.com.
_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals