From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14244 invoked by alias); 31 Oct 2004 16:28:14 -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 14233 invoked from network); 31 Oct 2004 16:28:12 -0000 Received: from unknown (HELO mta11.adelphia.net) (68.168.78.205) by sourceware.org with SMTP; 31 Oct 2004 16:28:12 -0000 Received: from mail.adelphia.net ([68.168.78.208]) by mta11.adelphia.net (InterMail vM.6.01.03.02 201-2131-111-104-20040324) with SMTP id <20041031162812.SIHQ2188.mta11.adelphia.net@mail.adelphia.net>; Sun, 31 Oct 2004 11:28:12 -0500 X-Originating-IP: [68.67.165.107] From: To: Skeezics Boondoggle , Subject: Re: Re: SDL Interface Development Date: Sun, 31 Oct 2004 17:45:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20041031162812.SIHQ2188.mta11.adelphia.net@mail.adelphia.net> X-SW-Source: 2004/txt/msg01374.txt.bz2 I concur on the dependencies. I have no problem with pulling in lots of 3rd party code, BUT 1. it should be OS-independent 2. it should be included inside the Xconq build. Otherwise, you can spend forever just trying to get everything to compile clean, before you can start any work. You've raised the barrier to entry so high, that nobody but the most fanatical will attempt to maintain the code. Which means the program will die out when the fanatics move on. Erik > > From: Skeezics Boondoggle > Date: 2004/10/31 Sun AM 03:52:32 EST > To: xconq7@sources.redhat.com > Subject: Re: SDL Interface Development > > On Sat, 30 Oct 2004, Eric McDonald wrote: > > [snip] > > A while back ago, we considered SDL_Pango for handling of > > international and exotic text. Pango (which SDL_Pango obviously > > requires) is not without dependencies either. So I think point (2) is > > something worth considering. How much should Xconq be able to stand > > alone? And how much should we cave in to rapid development at the > > expense of raising the hacker "cost of entry", so to speak? > [snip] > > 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. 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. > > Having lived through the years when "all the world's a Vax", 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. That's my only worry with using third party libs that come with > a mile-long dependency list... > > 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? :-) > > -- Chris > >