<br><br><div class="gmail_quote">2013/3/5 Frank Warmerdam <span dir="ltr"><<a href="mailto:warmerdam@pobox.com" target="_blank">warmerdam@pobox.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><div><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>1. Packages coming from various sources being made by hand in a non-regular fashion may cause the overall system fragile, incompatibilities between versions dependencies may likely happen. </div>
</blockquote>
<div><br></div></div><div>This is certainly true, but I also think it has been a substantial contributor to ability to get contributions from lots of projects which often have fairly ideosyncratic build configurations.</div>
<div class="im"><div>
 </div></div></div></div></blockquote><div><br></div><div><br></div><div><div>Hi Frank,</div><div><br></div><div>For me it's difficult to imagine a build process which cannot be automated. Automation may require some extra work, but we save much more efforts regarding to the subsequent builds. Each project may however require one time actions to install the prerequisites into the right places. This may indeed require contribution especially when upgrading those versions.</div>
</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>The overall build process is out of the control, it's quite difficult to reproduce at least the same build without requiring the package providers to participate. We are reusing  the same dependencies among various projects which is not necessarily be the only way to follow.</div>


<div>In my opinion if we continue to go with this multi-package concept, we could probably make it more reliable if we don't let the users to create their packages by hand. We should provide a build environment (a dedicated server) to provide the builds and the users should just author their build scripts which would check out the sources and compile it regularly or the build would be triggered by someone who is authorized to do it.</div>

</blockquote><div><br></div></div><div>I think this would substantially narrow the set of projects that end up getting incorporated though it would certainly be likely that they would be less fragile.</div><div class="im">
<div><br></div></div></div></div></blockquote><div><br></div><div>Not sure why. I don't think if the projects are not interested in being part of the build process. I also think it's a pressure for the contributors to regularly upgrade their binaries in the osgeo4w repository.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="gmail_quote"><div class="im"><div></div><div><br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>2. The current cygwin based installer is not necessarily be convenient for most Windows users.  I consider on Windows the users would rather require pre-bundled msi installers which would make things up and running instead of dealing versions and sub-package dependencies in mind. Users would not want to be in familiar with which version of zlib or curl is installed for MapServer or QGIS to run correctly. Installers may however contain feature selection options and further customizations according to the requirement of the project specifically. </div>

</blockquote><div><br></div></div><div>Hmm, to me this flies in the face of what I had hoped to accomplish with OSGeo4W.  I imagined it much like linux distributions such as Debian where only one copy of dependencies would exist on the system  except in very rare circumstances.  I think ou are describing a way of building essentially standalone installers for things like QGIS or MapServer that would be distinct and duplicating things like GDAL.  Is that right?  That could certainly have some value but it is quite different than what I dreamed of. </div>

<div><br></div><div>For instance I dreamed of a world where if one managed to install support for a GDAL plugin it would become available to all GDAL based packages on the system (well in the OSGeo4W world at least). </div>
<div class="im">
<div><br></div></div></div></div></blockquote><div><br></div><div>Not sure this is a concept that should be phased out. But this scheme would apply for the centralized build process I've mentioned. It is very difficult to provide consistent builds if the parts are produced in different environments and different authors. </div>
<div><br></div><div>We could also run the build scripts of the project installers as part of the build process. Installers would rely of the previously compiled files from OSGeo4w or it would also be possible to recompile different versions of certain dependencies if required.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="gmail_quote"><div class="im"><div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>For example QGIS and MapServer may have similar dependencies (like GDAL) but it not necessarily be the same version. Project may be installed into different target directories with different versions of the same dependencies side by side. This would let the projects provide more consistent builds without being affected by versions of external dependencies. Some of the projects may require further actions which could also be included in the installers as custom actions. For example we may probably install MapServer  with IIS registration, or bundled with a Web server like Apache or both. </div>


<div>We could however aim to use the same version of GDAL between multiple projects, but it would be essential to build the complete system in a centralized fashion and making sure about the correct build order according to the project hierarchies. Packages from a single project should also be build in a single process. I doubt it is a good solution for example to build GDAL core and the plugins or the bindings different times.</div>


<div><br></div><div>Since #1 is mostly about a build concept we could probably start with authoring the buildsystem and then build several installer on the top and the cygwin or the msi based packages could exist side by side.</div>

</blockquote><div><br></div></div><div>Despite my hesitancy on the above points, I am working with Alex Mandel to setup a windows build VM that I hope can be reasonably widely sharable and that could be used to reproduce some of the major dependencies like GDAL in a reproducible way. </div>

<div><br></div></div></div></blockquote><div><br></div><div>That seems to be promising indeed.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="gmail_quote">
<div></div><div>My original point to the board was that I hesitate to fire money at OSGeo4W as long as we are having trouble building a vision of how to proceed with it.  Certainly my view of Debian-like packaging has not got universal acclaim, nor has the current approach of haphazard hand building of packages always worked out well.</div>

<div><br></div></div></div></blockquote><div><br></div><div>I think not all of the (Windows) users are involved to see the details, just download the project installer and get it up and running. It would also be a requirement to get automated builds for the latest fixes, because it is not so easy to compile the binaries from sources in most cases.</div>
<div><br></div><div>Best regards,</div><div><br></div><div>Tamas</div><div><br></div></div>