This is the mail archive of the
xconq7@sources.redhat.com
mailing list for the Xconq project.
Re: Build system overhaul (Was: Tcl/Tk Interface Unification)
- From: Eric McDonald <mcdonald at phy dot cmich dot edu>
- To: Juergen Ruehle <j dot ruehle at bmiag dot de>
- Cc: xconq7 at sources dot redhat dot com, Hans Ronne <hronne at telia dot com>
- Date: Tue, 16 Sep 2003 09:37:52 -0400 (EDT)
- Subject: Re: Build system overhaul (Was: Tcl/Tk Interface Unification)
Hello Juergen et al.,
On Tue, 16 Sep 2003, Juergen Ruehle wrote:
> Please note that at least on cygwin the sdl build can't share the same
> library objects (e.g. kernel) with the other interfaces because it
> require different compiler options (i.e. -mno-cygwin) which result in
> different (and incompatible) sets of header files and libraries being
> used.
Yes, I noticed this. I am still sorting through how to best deal
with it. Adding the `sdl-config --static-libs` stuff to the
linker arguments in the SDL dir was only part of the fix, and
even that may still need some filtering. However, I think this
must be expanded to the kernel dir as well, and that in the case
of the SDL interface, HFLAGS = -mwin32 is not appropriate.
I will get back to this problem after I finish my current pass
through the build system.
> This could be worked around by creating non cygwin versions of the
> tcl/tk, curses, and x11 interfaces which is not easy, because the
> -mno-cygwin libc provides significantly less functionality which is no
> problem for xconq itself but definitely a problem for building the non
> cygwin versions of curses and the X11 libraries (for tcl/tk we can use
> the active state version?).
Or one could just have each interface do a "make
clean" on the kernel dir, and then pass/override the
appropriate make flags when making libconq.a and libconqlow.a.
> A general solution would therefore require providing a separate build
> directory for some interfaces (and consequently compiling the kernel
> more than once).
I think we both might be suggesting the same thing. You are
welcome to submit a patch if you would like to see this fixed
sooner rather than later. (Please note that you may want to change
some of the places where I use $(krnsrcdir) to a $(krnblddir) or
something along those lines.)
Eric