From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14081 invoked by alias); 17 Sep 2003 10:32:28 -0000 Mailing-List: contact xconq7-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: xconq7-owner@sources.redhat.com Received: (qmail 14049 invoked from network); 17 Sep 2003 10:32:28 -0000 Received: from unknown (HELO gimli.bmiag.de) (62.154.210.133) by sources.redhat.com with SMTP; 17 Sep 2003 10:32:28 -0000 Received: (qmail 9031 invoked by uid 111); 17 Sep 2003 10:31:50 -0000 Received: from mailgateway1.intranet.kiel.bmiag.de(192.168.254.119), claiming to be "bmiag.de" via SMTP by gimli.bmiag.de, id smtpdf8wwTV; Wed Sep 17 12:31:44 2003 Received: (qmail 28371 invoked by uid 5002); 17 Sep 2003 10:32:12 -0000 Received: from lapjr.intranet.kiel.bmiag.de (HELO LAPJR) (192.168.254.68) by mailgateway1.intranet.kiel.bmiag.de with SMTP; 17 Sep 2003 10:32:12 -0000 From: Juergen Ruehle MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16232.14328.274000.891577@lapjr.intranet.kiel.bmiag.de> Date: Wed, 17 Sep 2003 15:54:00 -0000 To: Eric McDonald Cc: xconq7@sources.redhat.com, Hans Ronne Subject: Re: Build system overhaul (Was: Tcl/Tk Interface Unification) In-Reply-To: References: <16230.54033.689000.36765@lapjr.intranet.kiel.bmiag.de> X-Virus-Scanner: scanned at mailgateway1.intranet.kiel.bmiag.de (d8a78d6c2bf9d7e344f673b1481681eb) X-SW-Source: 2003/txt/msg00425.txt.bz2 Hello Eric, > > A general solution would therefore require providing a separate build > > directory for some interfaces (and consequently compiling the kernel > > more than once). > > On second thought, how about we just make libconq_mw32.a and > libconqlow_mw32.a for anything that is doing a mingw32 build and > make the regular kernel libs (once, not multiple times) for > anything that is doing a cygwin or other build? > > This would save us the hassle of separate build dirs or remaking > the kernel multiple times. And since we are using special flags > with the mingw32 builds anyway, it should be trivial to make > us link against the alternate libraries as well. Would we have separate targets for these in kernel/Makefile or do we completely parameterize the build and pass in the flags and the target names from the calling Makefile? Are there more options? I like the second approach better, because it keeps all the special flags in one place (i.e. in sdl/Makefile which started this discussion in the first place) and (unlikely) future occurences of this problem would not require changes to kernel/Makefile.in, but the first solution seems much simpler to implement. But obviously it's up to whoever implements this (which probably wont be me:-) Happy hacking, jr