Frank, > I would suggest building it as an installer .exe, perhaps using NSIS as > I did for FWTools, or perhaps the method mentioned by Jurgen produces > a nice installer.
If possible, I would suggest the final output be a .msi (Windows Installer package) rather than a .exe. In an effort to make the average user more secure, Microsoft continues to clamp down on the flexibility afforded to .exe installers, due to the trouble of disambiguating them from malicious programs. It was a big shock when Windows Vista was introduced and it prevented .exe installers from truly running with administrative rights even if the logged on user was an administrator. Everybody knows about that issue now and has learned how to modify their .exe to request those rights (causing the user to be prompted for confirmation) but who knows what Microsoft will do next. For that reason, I believe it would be better to bite the bullet and adhere to their recommended installation format. Microsoft's Visual Studio has long had an easy mechanism for building .msi installers. It is what I would recommend for this, unless you prefer to use a FOSS alternative, in which case I cannot advise on what would be good. There are many. Perhaps Jürgen has a better idea. > One question not discussed is whether GDAL should be minimalist or > maximalist. That is, do we want to include as many formats as possible > despite the fact that it drags in lots of supporting libraries? If we > just use whatever decision OSGeo4W uses then we will have a fairly > maximalist solution which is ok I suppose but might make integration of > the resulting GDAL in other complex applications messy. IMO, there are two primary goals of this packaging of GDAL: provide easy access to just the GDAL command line utilities (separate from larger tool suites such as FWTools and OSGeo4W), and provide the GDAL libraries in a well-known location so they can be located by the various GDAL bindings. I think a secondary goal is to provide GDAL libraries in a well-known location for integration by arbitrary applications. Because the GDAL binaries will not normally be in the PATH, only when the user is wanting to use the GDAL utilities, the mere presence of a large number of supporting libraries will not be an issue. As you noted, it is when it comes to integration that there is a problem. I don't think there's an easy answer for the minimalist/maximalist question. I think it would be best to err on the maximimalist side, with the idea of providing as fully-functional command line suite as possible. But if there are particular libraries that are known to cause problems for popular integration scenarios but are rarely used by command-line users, then leave them out. I don't know how to identify such libraries; the GDAL team and power users are the best source of that info. Over time, you can hopefully ease any problems by moving things to plugins that are only loaded on demand, allowing someone to integrate without hitting a problem unless the plugin is loaded. In the end, integrators are likely to be skilled programmers and their fallback position will be to build a private copy of GDAL with the select dependencies they need. > I would like to suggest production of such an installer be done in such > a way that the generating scripts live in SVN somewhere, and with > instructions for the process in the wiki so it isn't all tied to one > person (as FWTools was). > > Man, I'm really tempted to leap into this myself but I have so many > other outstanding items right now. I am willing to assist in an > effort by a small (2-3 people?) team. I would be happy offer opinions, review, and test but am not available to lead at this point. As the developer of the primary source of Windows builds of GDAL, I think Tamas is the logical leader for this if he is available. Thank you for seeing this as an important priority. Jason _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
