Re: [boost] [all] Request for out of the box visibility support

Subject: Re: [boost] [all] Request for out of the box visibility support
From: Jeffrey Graham (jeffrey.graham.traclabs_at_[hidden])
Date: 2018-08-22 15:28:45

   On 08/21/2018 05:35 PM, Gavin Lambert via Boost wrote:

     On 21/08/2018 19:04, Olaf van der Spek wrote:

     IMO dynamic libs make sense if they're managed by the system, if you
     have to distribute / install them yourself chances are they're not
     going to be shared anyway.

     If your application consists of multiple separate executable
     binaries, then you might still want to distribute a library that
     they all share dynamically, even if it's private.
     And it is still possible to install libraries system-wide, although
     that tends to be more frowned on nowadays due to long years of
     people doing it wrong and installing something that breaks other
     applications.

     Full static, or something that's not easily possible today (AFAIK),
     building the library files directly as part of your project, ensures
     you always link to the same code and in the latter case ensures the
     lib is build with exactly the same settings as your project. The
     latter is like header-only libs..

     Yes, although the latter often brings its own headaches with the
     build environment (include paths and defined symbols, mostly), which
     is probably why it's not done as often.
     And also people often want to be able to compile a library once and
     then just use it rather than having to recompile it periodically.

     Static CRT is mostly (only?) an issue on Windows isn't it? If only
     MS
     / Windows itself would take care of installing it.

     I think you have some wires crossed.  The static CRT is compiled
     into an application, so by definition doesn't require installation
     at all.
     And the dynamic CRT is already installed as part of Windows -- every
     Windows version always includes all the previously-released CRTs
     bundled into it.  But until they invent a handy time machine, they
     can't bundle the runtimes that are released after the OS is
     released.  Sometimes they get included in Windows Update, sometimes
     not (traditionally only security fixes were included, not general
     feature releases).
     But in general if you're releasing some software that uses a runtime
     newer than the oldest version of Windows you're expecting it to run
     on, then you need to include the runtime in your installer, just in
     case. Or use the static CRT instead.
     This is not a Windows-only issue either -- it's just more common to
     use the latest Windows dev tools than it is to use the latest
     gcc/clang/stdlib on Linux, since the latter require complex building
     from source.  And then if you do that you would again either have to
     use the static runtime or distribute a dynamic runtime along with
     your binary if you expect it to be able to run on a system that only
     has the older runtime installed.  (Again, Linux seems less prone to
     this in general only due to the culture of compiling from source
     rather than distributing binaries, unless using binaries precompiled
     and distributed by the system vendor.)
     This is getting a bit off-topic anyway.

   All of these technical issues requiring so much effort and expertise
   now and for the foreseeable future.
   I would prefer to at least have the choice of pure header only for all
   libs, because I don't care how long my compile takes.