Re: boost macros use non-portable tac

[Peter Simons]

Hi Peter,

 > I looked into this and unfortunately Boost's naming conventions [1] are
 > way to complex to allow us to enumerate all possible combinations, and I
 > guess that's why the original author chose to use 'ls' with wildcards to
 > identify the name.

personally, I don't think it's important that the macros recognize all
those possible library names automatically. IMHO, it's perfectly alright
to ask the person calling ,/configure to provide the proper suffix on
the command-line. If the macros would recognize the most common library
names by themselves and relied on human help for everything else, I'd be
perfectly happy with them. My biggest grief with those macros as they
are right now is that they make all kinds of guesses that I cannot
influence if these guesses turn out to be wrong.

Anyway, that's just my 2 cents.


 > libboost_system[a-z0-9_\-]*.* where the second wildcard is platform
 > dependent suffix (e.g so on linux). I think there is no need to
 > enumerate these suffixes but let the globbing do the work. That would
 > solve the current problem that suffic dylib is not found.

Okay.


 > Second thing is when there are multiple installed versions, which one
 > to use? I agree with Diego that it one want to link against the most
 > recent one [...].

If the selection of available libraries is ambiguous, then ideally there
would be a way for the user to force a particular version/variant. In
the absence of such user information, using the latest version is
probably the best thing to do, though.


 > I'll try to come up with a patch considering these things the next few days.

Very cool. Thank your for your efforts in this matter.

Take care,
Peter