Re: [boost] cmake target and binary name mangling

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of P F via Boost Sent: 24 July 2017 00:40 To: boost@lists.boost.org Cc: P F Subject: Re: [boost] cmake target and binary name mangling

...

On Jul 23, 2017, at 5:23 PM, Niall Douglas via Boost wrote:

...

I would suggest that the CMake build for Boost should do things following the standard practices for CMake, and be as simple as possible.

I appreciate everything you've just said and the time you took to say it. But quite frankly, you're plain wrong:

1. The mangling pattern should be published with a formal regex for parsing it. It should never, ever change.

2. cmake lets external cmake override binary naming arbitrarily, so if you really want the binary to be called foo.so, you can go ahead and do that no problem because you know the mangling of the cmake target names, so you know which target sets to set properties for.

3. If you're working outside of cmake, cmake export writes config files which are of stable layout and which can be easily regex scanned for the name of the binary you need. Any bit of scripting can do this, even Windows batch. I've done this countless times, it's a really nice feature of cmake.

So everything you just said is all irrelevant. Meanwhile, there are *enormous* end user gains to mangling the binary name.

Then why does no linux distro do this?

Because it is Linux, not Microsoft Windows. Different rules apply. This is an endian issue - neither is overwhelming right, but having both is the worst. But that's where we are and it's too late now to get rid of different names now. Anyway, I think encoding the info in the name is a really good idea when the linking process is so stupid that it can't even tell me that I'm trying to link a single with a multithreaded or whatever other of the many possible mistakes.

Even when they support compiling for multiple platforms. I think the standard way is to use separate directories instead of using encoded name, which is very much relevant and current practice.

Not for me - it would be a crippling change to switch to use separate directories. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830