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"
loop.
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.
Braden
_______________________________________________
Gnash mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnash
