X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com X-Injected-Via-Gmane: http://gmane.org/ To: geda-user AT delorie DOT com From: Kai-Martin Knaak Subject: Re: [geda-user] Any new geda port for Windows? Date: Mon, 21 Jan 2013 20:11:03 +0100 Organization: Institut =?UTF-8?B?ZsO8cg==?= Quantenoptik Lines: 51 Message-ID: References: <8738y3iigd DOT fsf AT dome DOT home> <20130114231808 DOT 26630 DOT qmail AT stuge DOT se> <20130121034737 DOT 3686 DOT qmail AT stuge DOT se> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet AT ger DOT gmane DOT org X-Gmane-NNTP-Posting-Host: bibo.iqo.uni-hannover.de User-Agent: KNode/4.4.11 Reply-To: geda-user AT delorie DOT com Peter Stuge wrote: > Kai-Martin Knaak wrote: >> > It would be fantastic if the student could get in touch with the >> > project in order to make those builds automated somewhere. >> >> The build of the binaries is done on DJ's server by automated scripts. >> The results can be found at >> ftp://ftp.delorie.com/pub/geda-windows/snapshots/ > > Yes, they're a great first step, but they are not the installer. IMHO, the geda source distribution should contain a straight forward way to build a working windows installer. This should be much like the source provides a way to build a working linux environment with a only few commands on the CLI (i.e. autogen.sh --> configure --> install) Currently, the generation of a windows version requires a tool chain distributed over many parties: 1) the minipack build script by Cesar 2) a build of the windows binaries by DJ 3) a library of heavy symbols and a set of config files be me 4) integration in an installer by Klaus As the project evolves, each step is prone to failure. Since it is all detached from the main repository, there is no easy way to check if everything is still working fine. Consequently, the chain silently breaks. That's why I try to pool all the steps. Once we have a working chain here, the next step will be to improve the integration. Ideally, the windows installer should be a target of minipack. I found a blog on how this can be done on debian with the installer builder Klaus used: https://katastrophos.net/andre/blog/2009/03/16/setting-up-the-inno-setup-compiler-on-debian/ Running the whole minipack will be a tour de force of downloads and compiles. But bandwidth is cheap these days and so are processor cycles. However, the chain as outlined above does not work out of the box at the moment. See my minipack mileage in another thread. > I am not suggesting that it be committed as-is, but it would be good > as a starting point for a plain unaffiliated installer, right? Sure. To make an instantly usable distribution is a worthwhile goal. The installer assembled by Klaus is self-contained. In addition to the geda binaries it installs its own config files to the destination path. There is no external magic involved. The Inno-Setup environment used to assemble the installer is open sourced, too :-) ---<)kaimartin(>---