Re: [boost] cmake target and binary name mangling

Subject: Re: [boost] cmake target and binary name mangling
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2017-07-24 09:06:55

> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of P F via Boost
> Sent: 24 July 2017 00:40
> To: boost_at_[hidden]
> Cc: P F
> Subject: Re: [boost] cmake target and binary name mangling
> 
> 
> > On Jul 23, 2017, at 5:23 PM, Niall Douglas via Boost <boost_at_[hidden]> 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
[phone]