X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Date: Mon, 15 Aug 2016 06:12:12 +0200 (CEST) X-X-Sender: igor2 AT igor2priv To: "Evan Foss (evanfoss AT gmail DOT com) [via geda-user AT delorie DOT com]" X-Debug: to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu" From: gedau AT igor2 DOT repo DOT hu Subject: Re: [geda-user] [pcb-rnd] build change notification, windows port In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Reply-To: geda-user AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: geda-user AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Mon, 15 Aug 2016, Evan Foss (evanfoss AT gmail DOT com) [via geda-user AT delorie DOT com] wrote: > On Sun, Aug 14, 2016 at 5:38 PM, wrote: >> Hi all, >> >> if you have a pcb-rnd checkout older than a day, please run, in trunk/: >> >> svn up >> make distclean >> ./configure >> >> Fresh checkouts are not affected. >> >> Reason: major cleanup in the build system; config.manual.h is also >> deprecated and removed/ignored (in favor of ./configure parameters). >> >> In parallel to the build system cleaning, I managed to cross-compile pcb-rnd >> to windows. If you have access to windows and can spend some time testing >> pcb-rnd on it, please contact me in private. If there are enough testers >> pcb-rnd will feature windows binaries with each new release. > > Cool. What build setup are you using on windows? I decided to separat cross-compiling the dependencies and building pcb-rnd, because of the very different frequency of recompilation: deps should be compiled rarely, maybe every second year, while pcb-rnd evolves fast. I took the original mpk toolchain, bumped the version of some packages, added a pkg-config recipe to it and removed pcb. I still need to generate a patch for gtk, but other than that it can cross-compile all the dependencies now. (NOTE: scconfig has a host/target terminology different than autoconf's: host is where we compile, target is where the resulting executables should run) I mainly used the windows cross compilation as an excuse to clean up the remaining config.h issues, to finish the scconfig integration and make sure it all works in cross-compilation and to "exotic targets" without making the generic part of the code a mess of #ifdefs: - added some new detections in scconfig (e.g. for rint()) - dropped the "#define HAVE_FOO_H" custom in favor of the more flexible generated #include lines (see trunk/src/compat_inc.h.in) - one of the things where scconfig design is more advanced than autoconfig's in practice - grouped all system dependent #ifdef and include-generation and other portability related code in src/compat*.[ch], behind a simple API, so the rest of the code is clean of these (you just need to use pcb_strdup() vs. strdup(), pcb_mkdir() vs. mkdir(), etc, but don't need to do #ifdefs anywhere else); while this is also possible with autoconfig, for some reason most projects don't do this - separated host and target commands in the Makefiles, e.g. compiling windows binaries on a linux machine means "make install" should use cp, not copy (this why I needed a cross-compilation setup in the first place, to be able to test this) So the build setup is the mpk-compiled pack of dlls and headers, then normal scconfig (in cross-compilation mode with mingw for compiling and wine for running the detection tests and the mpk-compiled pkg-config so it finds the right gtk - just a few extra arguments for ./configure). This week I check if the pre-alpha binary pack for windows triggers similar user activity as the Mac OS X port did. If so, I will fix the remaining bugs and put online a stable windows binary pack with each release. If not, it remains a theoretical feature that was used as a test bed while finihsing scconfig integration. Regards, Igor2