Re: boost macros use non-portable tac

[Peter Johansson]

On 09/27/2012 07:01 PM, Peter Simons wrote:
> >  One could try first try linking against '-lboost_system-mt' and then
>   >  against '-lboost-system'. The linker knows much better than us what
>   >  suffixes libraries have on the system. If people don't mind that
>   >  change, I can prepare a patch. WDYT?
>
> IMHO, using the linker to determine which of those libraries exist is
> the way to go. I'm very much in favor of that.
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. All names, however, match

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.

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, so if there are, for example, 'libboost_system-1_43.so' as well as 
'libboost_system-1_51.so' installed one want to link against the latter. 
IMVHO, it would be better if boost kept the version out of the stem of 
the library name and I've noticed that's what is done on the two systems 
I have access to, RHEL and mac port. Anyway, the bottom line is that 
when the version is in the library name we should pick the one with 
highest number. I would also prefer to pick versions with multithreads 
enabled i.e. with string '-mt'. But that's my preference.

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

Cheers,
Peter

[1] 
http://www.boost.org/doc/libs/1_51_0/more/getting_started/unix-variants.html#library-naming