[Xastir-dev] --with-bdb-include=/sw/include/db4

[Tom Russo]

On Fri, Dec 10, 2004 at 04:21:54PM -0500, we recorded a bogon-computron collision of the <shadow at dementia.org> flavor, containing:
> On Fri, 10 Dec 2004, Curt Mills wrote:
> 
> >On Fri, 10 Dec 2004, Derrick J Brashear wrote:
> >
> >>It assumes it's not dangerous to add checks for every package system's new
> >>and different idea of where stuff should go. Is that really a good
> >>assumption to make?
> >
> >We already have specific tweaks in there to support different
> >operating systems.  I just added another one yesterday that turns
> >off compiler optimizations if you're running Cygwin.  It should
> >really speed up compiles, perhaps taking less memory as well.  Worth
> >it I think.

The Cygwin-specific stuff needed to be added primarily because there's 
something in configure that overrides user-specified CFLAGS, so trying to shut 
off optimization can't be done on the configure command line.  If that were 
removed and something like:

 CFLAGS="-O0" ./configure

worked, then there would be need only for users who have the problem to 
specify options that fix it.  As it is, specifying that is a no-op, because
later on configure simply overrides CFLAGS.  There are those folks who have 
beefy Windows machines with plenty of memory who are now getting unoptimized 
code under Cygwin for no reason.

> >Where would we draw the line if we start asking questions like this?
> >Just support package systems where we have XX number of users or
> >more complaining?  Support all that we have time/energy for, so that
> >max number of users can run Xastir?  I suggest we do that last,
> >until it becomes too much of a burden.
> 
> 3) just because we don't default to looking in the *default* location for 
> Fink (it can be relocated, at least if it has any flexibility) doesn't 
> mean we don't support it
> 4) the best answer is still for a Fink user to contribute it to Fink.
> 
> But if you all think I'm wrong I'll do it when I get back to Pittsburgh. I 
> am 6 time zones away today.

I'm with Derrick on this one.  Putting all sorts of system-specific
(and package-management system-specific) oddball probes into configure is not 
"dangerous" but it is not quite what configure is meant to do.  If we start
(or even continue) down that path, configure will be an unmaintainable mess
in short order.  There are simply too many systems and package management
systems to make this a reasonable approach.  

Configure should not be expected to guess every non-standard location of
every possible package a developer makes the code depend on.  It should 
provide the user with the means to specify where to find things that can't be 
found with a simple set of probes.  For the most part we have that.  What 
there should be is some system specific user notes in READMEs, telling new 
users that if they're installing libraries from package-management system 
Fooble, they will likely need additional configure options to locate their 
installed libraries, and tell them what those options are.   Expecting 
"./configure" with no arguments to work 100% for all optional features on 
all systems is unrealistic, and puts the burden on the code maintainers to 
keep track of all those systems' peculiarities.  

-- 
Tom Russo    KM5VY     SAR502  DM64ux         http://www.swcp.com/~russo/
Tijeras, NM  QRPL#1592 K2#398  SOC#236 AHTB#1 http://www.qsl.net/~km5vy/
 "That which does not kill me is better than that which does."
    --Irving Nietzche, lesser known of the famous Nietzche twins