[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnash] Problem in compiling gnash from CVS

From: Rob Savoye
Subject: Re: [Gnash] Problem in compiling gnash from CVS
Date: Thu, 05 Oct 2006 15:37:36 -0600
User-agent: Thunderbird (X11/20060913)

Braden McDaniel wrote:

> They don't have to guess; they can look and see what they have. It does
> push more responsibility onto the user; but it's also guaranteed to be
> workable without requiring users to modify configure or makefiles (which
> is *really* unfriendly).

  Expecting the users to do anything isn't a good idea. I may add an
option that lets one specify the full name to the Boost thread library
though, which would accomplish the same thing.

> Dismissing some of the more obscure toolsets--como, cw, dm, edg, kcc,
> kylix, *-stlport, msvc, vc7--we are left with 13. Since this could be
> absent, this alone puts you at 14 potential library names. -mt may or
> may not be there, so we're up to 28 now. Dismissing STLport features
> leaves us with 4, so that's 112 possible library names.

 The number I believe is much smaller that 112. We can ignore most of
these other compilers, and they install each library with multiple
names. We only have to get one right. In the case of the Boost thread
library, I see libboost_thread, libboost-thread, libboost_thread-mt, and
libboost-thread-gcc-mt. Those are all links to the fully qualified file

> The idea that any additional toolsets or features that are added in the
> future act as a multiplier on this number amounts to just too much for
> me to consider maintaining. But I guess we have different thresholds.

  It's a question of where to put ones time. Me, I'd rather hack on
configure scripts, and have a big loop that tries all the various names
than answer endless bug reports and email about "where is my Boost
library", where I have to tell them to go look for it.

        - rob -

reply via email to

[Prev in Thread] Current Thread [Next in Thread]