From: Dave M. <win...@nt...> - 2005-08-26 09:32:25
|
14f...@sn... wrote: > Hmm, now that sounds neat as well :) although NSIS is not MSI (which > was my reason to not look into it, as it apparently doesn't work as > cleanly as NSIS - they question is though if users will notice ;) > Sent this earlier but got moderated due to large attachments. Hosted them on webspace now. the precompiled installer/updater http://devkitpro.org/files/MinGWUpdater-1.0.0.rar the nsis script and required data files http://devkitpro.org/files/installer_src.rar Well, personally I think the MSI approach would add another burden to the package maintainers. Here's my first cut at an NSIS based installer. On first install this app will allow the user to pick a sourceforge mirror site and request download only or download and install. The second dialogue gives a choice of Previous, Current and Candidate packages moving on to pick individual components, install directory and Start Menu. If the required tarballs aren't found in the same directory as the installer/updater they will be downloaded from the chosen mirror then extracted to the chosen install directory. Subsequent runs of the application enter update mode where the user can choose to install packages not installed on the first run or update installed packages with newer versions. The installer/updater is copied to the install directory and an "update" shortcut inserted in the start menu group. This is all acheived through an ini file which gives the name of the current tarball for each component of each install type. The first section is a version for the installer itself and allows for the app to update itself. The trailing |0 on each tarball would be the installed size to allow the installer to calculate disk space requirements. The ini file itself is both embedded in the installer ( but an ini of the same name in the same directory overrides this to allow for an installer package which does not require net access) and would be hosted on the mingw website. A package maintainer would merely have to upload a new tarball and edit the appropriate line in the hosted ini file. For what it's worth the plugin used to extract the tarballs can also handle bzip2 and lzma compressed tarballs, both of which would reduce the size of the downloads. [mingwupdate] Build=1 URL=http://www.mingw.org Filename=mingwupdate-1.0.0.exe [current] runtime=mingw-runtime-3.7.tar.gz|0 w32api=w32api-3.2.tar.gz|0 binutils=binutils-2.15.91-20040904-1.tar.gz|0 core=gcc-core-3.4.2-20040916-1.tar.gz|0 gpp=gcc-g++-3.4.2-20040916-1.tar.gz|0 g77=gcc-g77-3.4.2-20040916-1.tar.gz|0 ada=gcc-ada-3.4.2-20040916-1.tar.gz|0 java=gcc-java-3.4.2-20040916-1.tar.gz|0 objc=gcc-objc-3.4.2-20040916-1.tar.gz|0 make=mingw32-make-3.80.0-3.tar.gz|0 [previous] runtime=mingw-runtime-3.6.tar.gz|0 w32api=w32api-3.1.tar.gz|0 binutils=binutils-2.13.90-20030111-1.tar.gz|0 core=gcc-core-3.3.1-20030804-1.tar.gz|0 gpp=gcc-g++-3.3.1-20030804-1.tar.gz|0 g77=gcc-g77-3.3.1-20030804-1.tar.gz|0 ada=gcc-ada-3.3.1-20030804-1.tar.gz|0 java=gcc-java-3.3.1-20030804-1.tar.gz|0 objc=gcc-objc-3.3.1-20030804-1.tar.gz|0 [candidate] runtime=mingw-runtime-3.7.tar.gz|0 w32api=w32api-3.2.tar.gz|0 binutils=binutils-2.15.94-20050118-1.tar.gz|0 core=gcc-core-3.4.4-20050522-1.tar.gz|0 gpp=gcc-g++-3.4.4-20050522-1.tar.gz|0 g77=gcc-g77-3.4.4-20050522-1.tar.gz|0 ada=gcc-ada-3.4.4-20050522-1.tar.gz|0 java=gcc-java-3.4.4-20050522-1.tar.gz|0 objc=gcc-objc-3.4.4-20050522-1.tar.gz|0 Obviously there's still a little tidying to be done ( license screen for one and detection of Windows version for purposes of path inserion) but I think this is pretty close to what's needed. Constructive criticism appreciated. Dave |