From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14907 invoked by alias); 31 Oct 2004 18:57:17 -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 14556 invoked from network); 31 Oct 2004 18:57:15 -0000 Received: from unknown (HELO sccrmhc11.comcast.net) (204.127.202.55) by sourceware.org with SMTP; 31 Oct 2004 18:57:15 -0000 Received: from [192.168.181.128] (unknown[67.176.41.158](misconfigured sender)) by comcast.net (sccrmhc11) with ESMTP id <20041031185714011002rtjfe>; Sun, 31 Oct 2004 18:57:15 +0000 Message-ID: <41853581.3030201@phy.cmich.edu> Date: Sun, 31 Oct 2004 19:04:00 -0000 From: Eric McDonald User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) MIME-Version: 1.0 To: Skeezics Boondoggle CC: xconq7@sources.redhat.com Subject: Re: SDL Interface Development References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004/txt/msg01381.txt.bz2 Hi Skeezics, glad to see you're still hanging around, Skeezics Boondoggle wrote: > Just to chime in from the Solaris camp - this all sounds great, as long as > the dependent libraries are reasonably cross-platform and the build for > non-Linux/Windows machines (is that the diplomatic way to say "real Unix" > machines? :-) doesn't become untenable. Yeah, I remember that you had this concern when we first started seriously discussing moving to the SDL interface. I did do some research and found an old SDL package (I think it was a Sun package, but it was an RPM; that was some time ago) for Slowaris 7. If you find some time, you might want to just see if the newer SDL sources compile on one of your more modern boxen. >I'd say if it's smaller/easier to > bundle those libs with the Xconq sources and build them all in one shot, > that's fine, or we'd need to make sure that the configure script can > easily find them (or be told where to find them) already installed on the > system. Sure, there will definitely be some 'configure.in' and 'aclocal' hacking to be done. No big deal. Fortunately, all (IIRC) of the packages in question are autoconffed, and so they can be slaved to the Xconq configure script if we chose to make a great, grand source tarball containing all of the goods.... > Having lived through the years when "all the world's a Vax", Reminds me of fortune adapted from Shakespeare that I once read: All the world's a VAX, And all the coders merely butchers; They have their exits and their entrails; And one int in his time plays many widths, His sizeof being N_ bytes. At first the infant Mewling and puking in the Regent's arms. And then the whining schoolboy, with his Sun, And shining morning face, creeping like slug Unwillingly to school. -- A Very Annoyed PDP-11 >then the > period of "all the world's a Sun" and now "all the world's the hacked up > one-off peculiar Linux box on my desk", I'm just *reeeeeally* tired of > constantly screwing around with and patching configure scripts that assume > too much. You should see what I had to do to Xconq's aclocal in order to find and use Tcl/Tk on all the various odd Debian and Cygwin configurations.... >That's my only worry with using third party libs that come with > a mile-long dependency list... I worry about the same, but as long as I get feedback, I think we will do okay. Also, the dep list is not so long as for Gimp or Abiword. This one is fairly manageable, I think. > Also, I've been remiss in building xconq from the latest CVS snapshots for > Solaris... I think something was broken the last time I tried it... oh > geez, almost a year ago! (November 15th, 2003) I should grab the latest > sources and see if the existing stuff still builds on Solaris before > griping about possible future changes, eh? :-) Let me know if something is wrong. Regards, Eric