RE: [mapguide-internals] build script confusion RFC62???

14 messages Options
Embed this post
Permalink
Trevor Wekel-3

RE: [mapguide-internals] build script confusion RFC62???

Reply Threaded More More options
Print post
Permalink
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: [hidden email] [mailto:[hidden email]] 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:

> Hi UV,
>
> The process for RFCs is described on this page: http://mapguide.osgeo.org/psc.html.
>
> Is this what you're looking for?
>
> Cheers
> Tom
>
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] 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
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
> _______________________________________________
> 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
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
UV wild

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

Reply Threaded More More options
Print post
Permalink
Some javascript/style in this post has been disabled (why?)
Trevor,

Thanks for pointing this out. I was pondering on this issue already.
I think the inconsistencies are coming from VS building into  bin/$(Config) and the need to bring the libs together.

The solution to this can be simple as introducing a new target for the build and dropping the default target bin\$(Config) for binaries
We can keep the $(Config) part but instead of using the default target
we rearrange the targets according to the new standards.
(I.e we can have build the server into MGDev/Server/Deploy/$(Config)/Bin)

$(config)/bin
$(config)/bin/FDO or $(config)/FDO????
$(config)/Schema
$(config)/Repository
$(config)/....etc...

In the moment the build server fails because the FDO SDK puts the binaries in BIN but the build expects them in BIN\$(config)
this is a good example of how to frustrate newbies. So the SDK actually does not match what mapguide build expects.
Maybe the best thing is to remove the $(Config) part of the path in the mapguide build!?!?!?!
Then we would just overwrite the existing files in MgDev/Oem/FDO/bin and add an empty file to identify which config it is!
Due to the identical names this is an option I believe.

In the end the build server uses the solution files. Instead of the mix of msbuild and scripts
we could introduce an installation target for a postbuild.mak PostBuild project,
This could use either a default relative location or an environment variable to deploy the results into the MapGuide build tree.

Once this is established we realign the linux build to do the same.


Trevor Wekel wrote:
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: [hidden email] [[hidden email]] 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:
  
Hi UV,

The process for RFCs is described on this page: http://mapguide.osgeo.org/psc.html.

Is this what you're looking for?

Cheers
Tom


-----Original Message-----
From: [hidden email] [[hidden email]] 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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals
_______________________________________________
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
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

  


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

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

Reply Threaded More More options
Print post
Permalink
In reply to this post by Trevor Wekel-3
Some javascript/style in this post has been disabled (why?)
Trevor,

Oops, I just read your mail again and realise that I did read it properly.
I kind of like the idea of spreading things out like this.

But I think we should agree on one important goal:
To support a devel,build,debug cycle efficiently its imperative to have the server functional from the place the debug build puts it.

Furthermore this deploy location should depend on a single variable/macro with a meaningful default.
Which could be coming from the environment but it ALWAYS should have a default which is functional without any environment variables.
Such an approach would simplify the build process and running the test suites a lot.

So AFAIK the only libs whose loading location is configurable are the FDO libs
This means that the platform libs need to be deployed into the same directory as the server executable since depending on path variables for this introduces further configuration problems.
Instead we could introduce another configuration value for the Platform libraries and modify the DLL Loader for them.
Worth a consideration though.



Trevor Wekel wrote:
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: [hidden email] [[hidden email]] 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:
  
Hi UV,

The process for RFCs is described on this page: http://mapguide.osgeo.org/psc.html.

Is this what you're looking for?

Cheers
Tom


-----Original Message-----
From: [hidden email] [[hidden email]] 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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals
_______________________________________________
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
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

  


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

RE: [mapguide-internals] build script confusion RFC62???

Reply Threaded More More options
Print post
Permalink
Some javascript/style in this post has been disabled (why?)

Hi All,

 

I have to follow-up on Jason’s statement that any significant change in the FDO build/install needs an RFC so that we can asses impact and plan accordingly. I also re-iterate Trevor’s statement that there is a clear separation between build and install directory structures. It seems that MapGuide is using a variant of the current FDO install structure. I think we could come to some agreement on the install structure, but changes to the build structure would require much more consideration.

 

Greg                                                                                                                                                                                                                                              

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of UV
Sent: Friday, April 17, 2009 1:03 AM
To: FDO Internals Mail List
Subject: Re: [mapguide-internals] [fdo-internals] build script confusion RFC62???

 

Trevor,

Oops, I just read your mail again and realise that I did read it properly.
I kind of like the idea of spreading things out like this.

But I think we should agree on one important goal:
To support a devel,build,debug cycle efficiently its imperative to have the server functional from the place the debug build puts it.

Furthermore this deploy location should depend on a single variable/macro with a meaningful default.
Which could be coming from the environment but it ALWAYS should have a default which is functional without any environment variables.
Such an approach would simplify the build process and running the test suites a lot.

So AFAIK the only libs whose loading location is configurable are the FDO libs
This means that the platform libs need to be deployed into the same directory as the server executable since depending on path variables for this introduces further configuration problems.
Instead we could introduce another configuration value for the Platform libraries and modify the DLL Loader for them.
Worth a consideration though.



Trevor Wekel wrote:

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: [hidden email] [[hidden email]] 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:
  
Hi UV,
 
The process for RFCs is described on this page: http://mapguide.osgeo.org/psc.html.
 
Is this what you're looking for?
 
Cheers
Tom
 
 
-----Original Message-----
From: [hidden email] [[hidden email]] 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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals
_______________________________________________
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
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
 
  

 


_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Helio Chissini de Castro

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

Reply Threaded More More options
Print post
Permalink
On Sexta-feira 17 de abril 2009 09:41:18 Greg Boone wrote:

> Hi All,
>
> I have to follow-up on Jason's statement that any significant change in the
> FDO build/install needs an RFC so that we can asses impact and plan
> accordingly. I also re-iterate Trevor's statement that there is a clear
> separation between build and install directory structures. It seems that
> MapGuide is using a variant of the current FDO install structure. I think
> we could come to some agreement on the install structure, but changes to
> the build structure would require much more consideration.
>
> Greg
>

If mg go down this road in near future, can i mumble about Cmake something
again ? :-)

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

RE: [mapguide-internals] build script confusion RFC62???

Reply Threaded More More options
Print post
Permalink
Cmake is still an open idea and the RFC is still pending. Now that 3.4 is out, we can start discussing it again if you wish.

Greg

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Helio Chissini de Castro
Sent: Friday, April 17, 2009 9:49 AM
To: FDO Internals Mail List
Subject: Re: [mapguide-internals] [fdo-internals] build script confusion RFC62???

On Sexta-feira 17 de abril 2009 09:41:18 Greg Boone wrote:

> Hi All,
>
> I have to follow-up on Jason's statement that any significant change in the
> FDO build/install needs an RFC so that we can asses impact and plan
> accordingly. I also re-iterate Trevor's statement that there is a clear
> separation between build and install directory structures. It seems that
> MapGuide is using a variant of the current FDO install structure. I think
> we could come to some agreement on the install structure, but changes to
> the build structure would require much more consideration.
>
> Greg
>
If mg go down this road in near future, can i mumble about Cmake something
again ? :-)

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

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Trevor Wekel-3

RE: [mapguide-internals] build script confusion RFC62???

Reply Threaded More More options
Print post
Permalink
In reply to this post by Trevor Wekel-3
Hi Hugues,

>From what I recall, the coordinate system definitions reside in this directory.  Are the located somewhere else now?

Thanks,
Trevor

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Hugues Wisniewski
Sent: Monday, April 20, 2009 10:34 AM
To: MapGuide Internals Mail List; FDO Internals Mail List
Subject: RE: [mapguide-internals] [fdo-internals] build script confusion RFC62???

Hi,

I don't understand the 11g subfolder in CsMap
What is it?
Thanks

Hugues

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Trevor Wekel
Sent: Thursday, April 16, 2009 6:22 PM
To: MapGuide Internals Mail List; FDO Internals Mail List
Subject: RE: [mapguide-internals] [fdo-internals] build script confusion RFC62???

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: [hidden email] [mailto:[hidden email]] 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:

> Hi UV,
>
> The process for RFCs is described on this page: http://mapguide.osgeo.org/psc.html.
>
> Is this what you're looking for?
>
> Cheers
> Tom
>
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] 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
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
> _______________________________________________
> 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
_______________________________________________
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
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Trevor Wekel-3

RE: [mapguide-internals] build script confusion RFC62???

Reply Threaded More More options
Print post
Permalink
Ok.  Thanks Hugues.  I was not aware of the updated installation path.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Hugues Wisniewski
Sent: Monday, April 20, 2009 10:45 AM
To: MapGuide Internals Mail List; FDO Internals Mail List
Subject: RE: [mapguide-internals] [fdo-internals] build script confusion RFC62???

Hi Trevor,

They get built inside CsMap\Dictionaries
They get installed on a Windows platform inside:
"C:\Documents and Settings\All Users\Application Data\Autodesk\Geospatial Coordinate Systems"
It can be a different path and in that case that path is the value of the system variable MENTOR_DICTIONARY_PATH
I'm not sure how it work on Linux though if your original email was about Linux

Hugues


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Trevor Wekel
Sent: Monday, April 20, 2009 9:39 AM
To: MapGuide Internals Mail List; FDO Internals Mail List
Subject: RE: [mapguide-internals] [fdo-internals] build script confusion RFC62???

Hi Hugues,

>From what I recall, the coordinate system definitions reside in this directory.  Are the located somewhere else now?

Thanks,
Trevor

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Hugues Wisniewski
Sent: Monday, April 20, 2009 10:34 AM
To: MapGuide Internals Mail List; FDO Internals Mail List
Subject: RE: [mapguide-internals] [fdo-internals] build script confusion RFC62???

Hi,

I don't understand the 11g subfolder in CsMap
What is it?
Thanks

Hugues

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Trevor Wekel
Sent: Thursday, April 16, 2009 6:22 PM
To: MapGuide Internals Mail List; FDO Internals Mail List
Subject: RE: [mapguide-internals] [fdo-internals] build script confusion RFC62???

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: [hidden email] [mailto:[hidden email]] 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:

> Hi UV,
>
> The process for RFCs is described on this page: http://mapguide.osgeo.org/psc.html.
>
> Is this what you're looking for?
>
> Cheers
> Tom
>
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] 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
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
> _______________________________________________
> 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
_______________________________________________
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
_______________________________________________
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
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Greg Boone

CMakeLists

Reply Threaded More More options
Print post
Permalink
In reply to this post by Greg Boone
Helio,

As a start on moving this RFC forward, why don’t you submit the "CMakeLists.txt" files that you have ready, and we can go from there.

Greg

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Greg Boone
Sent: Friday, April 17, 2009 10:12 AM
To: FDO Internals Mail List
Subject: RE: [mapguide-internals] [fdo-internals] build script confusion RFC62???

Cmake is still an open idea and the RFC is still pending. Now that 3.4 is out, we can start discussing it again if you wish.

Greg

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Helio Chissini de Castro
Sent: Friday, April 17, 2009 9:49 AM
To: FDO Internals Mail List
Subject: Re: [mapguide-internals] [fdo-internals] build script confusion RFC62???

On Sexta-feira 17 de abril 2009 09:41:18 Greg Boone wrote:

> Hi All,
>
> I have to follow-up on Jason's statement that any significant change in the
> FDO build/install needs an RFC so that we can asses impact and plan
> accordingly. I also re-iterate Trevor's statement that there is a clear
> separation between build and install directory structures. It seems that
> MapGuide is using a variant of the current FDO install structure. I think
> we could come to some agreement on the install structure, but changes to
> the build structure would require much more consideration.
>
> Greg
>
If mg go down this road in near future, can i mumble about Cmake something
again ? :-)

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

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Helio Chissini de Castro

Re: CMakeLists

Reply Threaded More More options
Print post
Permalink
Em Segunda-feira 27 de abril 2009, às 14:05:24, Greg Boone escreveu:
> Helio,
>
> As a start on moving this RFC forward, why don’t you submit the
> "CMakeLists.txt" files that you have ready, and we can go from there.
>
> Greg

I gone a little further.
Here's attached the first full rewrite of whole cmake build, for fdo trunk.
95% of FDO Core is done, and i expect have providers done in a few days.

I took care of make possible as a default using system libraries, but user
just need set a cmake option to compile Thirdparty ones if needed, so almost
Best of Both Worlds

On the patch, a CMake__README.txt is created explaining everything. Now is
Unix/Linux only but i'm aiming Windows too.

I ask if i can have my commit access granted then i can maintain this
buildsystem more often not relying on my external repositories

[]'s

--
Helio Chissini de Castro
KDE Developer
Brasil/South America Primary Contact


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

fdo-trunk-unix-cmake.patch.zip (32K) Download Attachment
Jason Birch

RE: CMakeLists

Reply Threaded More More options
Print post
Permalink
I would be in favour of granting Helio commit access with the understanding that it only be used to commit / modify the CMake build system, and that modifications to the existing build system, FDO, or providers would still need to be submitted via patches until the FDO developers feel comfortable enough with his contributions to grant full commit status.  

This is in keeping with the concept of "Partial Commit Access" in Fogel's Producing OSS book, it's what I have with the MapGuide project to maintain the Windows installer, and I feel that it's a good fit in this case.  Thoughts?

http://producingoss.com/en/committers.html#partial-committers

Jason

________________________________________
From: Helio Chissini de Castro
Sent: Friday, May 15, 2009 10:32 AM
Subject: Re: [fdo-internals] CMakeLists

I ask if i can have my commit access granted then i can maintain this
buildsystem more often not relying on my external repositories_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Greg Boone

RE: CMakeLists

Reply Threaded More More options
Print post
Permalink
I have no issues with Helio submitting the CMake files. There are a few Thirdparty build files in his patch. Specifically to files in Thirdparty/openssl. We would have to test the changes to those files in the current build process once the submissions are made.

The other source files changes look ok.

Greg

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Jason Birch
Sent: Friday, May 15, 2009 2:08 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] CMakeLists

I would be in favour of granting Helio commit access with the understanding that it only be used to commit / modify the CMake build system, and that modifications to the existing build system, FDO, or providers would still need to be submitted via patches until the FDO developers feel comfortable enough with his contributions to grant full commit status.  

This is in keeping with the concept of "Partial Commit Access" in Fogel's Producing OSS book, it's what I have with the MapGuide project to maintain the Windows installer, and I feel that it's a good fit in this case.  Thoughts?

http://producingoss.com/en/committers.html#partial-committers

Jason

________________________________________
From: Helio Chissini de Castro
Sent: Friday, May 15, 2009 10:32 AM
Subject: Re: [fdo-internals] CMakeLists

I ask if i can have my commit access granted then i can maintain this
buildsystem more often not relying on my external repositories_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Greg Boone

RE: CMakeLists

Reply Threaded More More options
Print post
Permalink
Jason, if you feel that Helio's committer rights needs to be put to a vote, go ahead and make the motion.

Greg

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Greg Boone
Sent: Friday, May 15, 2009 2:21 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] CMakeLists

I have no issues with Helio submitting the CMake files. There are a few Thirdparty build files in his patch. Specifically to files in Thirdparty/openssl. We would have to test the changes to those files in the current build process once the submissions are made.

The other source files changes look ok.

Greg

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Jason Birch
Sent: Friday, May 15, 2009 2:08 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] CMakeLists

I would be in favour of granting Helio commit access with the understanding that it only be used to commit / modify the CMake build system, and that modifications to the existing build system, FDO, or providers would still need to be submitted via patches until the FDO developers feel comfortable enough with his contributions to grant full commit status.  

This is in keeping with the concept of "Partial Commit Access" in Fogel's Producing OSS book, it's what I have with the MapGuide project to maintain the Windows installer, and I feel that it's a good fit in this case.  Thoughts?

http://producingoss.com/en/committers.html#partial-committers

Jason

________________________________________
From: Helio Chissini de Castro
Sent: Friday, May 15, 2009 10:32 AM
Subject: Re: [fdo-internals] CMakeLists

I ask if i can have my commit access granted then i can maintain this
buildsystem more often not relying on my external repositories_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Helio Chissini de Castro

Re: CMakeLists

Reply Threaded More More options
Print post
Permalink
In reply to this post by Greg Boone
Em Sexta-feira 15 de maio 2009, às 15:21:25, Greg Boone escreveu:
> I have no issues with Helio submitting the CMake files. There are a few
> Thirdparty build files in his patch. Specifically to files in
> Thirdparty/openssl. We would have to test the changes to those files in the
> current build process once the submissions are made.
>
> The other source files changes look ok.
>
> Greg

Disregard all openssl changes. This came when i made an svn diff after build
the internal one, and those files are generated by the build. Is nothing that i
modified by hand, so no openssl changes are needed.

The only real source changes are the include headers on FDO source and the
addition of "%s" on some fprintf, since we build here with
-Wfortmat -Werror=format-security  which makes gcc fail when detect code with
possible buffer underrun issues.

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