[Top][All Lists]

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

Re: [Gnash] Problem in compiling gnash from CVS

From: Braden McDaniel
Subject: Re: [Gnash] Problem in compiling gnash from CVS
Date: Thu, 05 Oct 2006 17:20:56 -0400
User-agent: Thunderbird (Windows/20060719)

Rob Savoye wrote:
Braden McDaniel wrote:

That's not the only choice; you can use the solution I provided instead.

  I wouldn't want users to have to guess the name of the correct suffix
when if can be found automatically by configure.

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).

You do have your work cut out for you if you pursue the approach you
describe above, though. Have a look at

  This was the easy solution, to just have a list of all the names used
for the thread library, and execute the searching code in a big "for"

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 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.

> Personally, having so many names for the libraries is a really bad
> idea.

I agree. It comes from Windows-think, where it's often inconvenient to modify path variables, and thus customary to throw all your libraries into the same directory.


reply via email to

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