Re: [boost] Extremely large Visual Studio libboost_log_setup* binaries

On Wed, Jul 3, 2013 at 11:07 PM, Tom Kent wrote:

On Wed, Jul 3, 2013 at 12:11 PM, Andrey Semashev wrote:

...

Also, compare apples to apples. The OP mentions the space needed to build Boost, not the size of the actual binaries you get.

I was referring to the actual binaries that you get, I didn't even look at the space needed to build. The reason I noticed this is because the Windows binaries that I publish for public consumption doubled in size with this release.

Oh, I misinterpreted your message then, sorry.

I had already received comments that the boost binaries were too big, I'm seriously worried that this further increase will negatively impact usage of the entire boost library.

Well, you will face this problem sooner or later, since Boost is growing constantly. I think, eventually installer will have to get modularized, much like Boost itself is getting now. That doesn't mean I don't want to reduce Boost.Log binary size.

The user can disable portions of the library he doesn't need by defining

...

config macros. E.g. disabling wchar_t support can reduce the size by approximately 50%. Disabling parsers altogether will make boost_log_setup* practically empty.

Maybe we need to look at making these the defaults. What do you mean by "parsers" in this context, is this a core functionality of log? Sorry if these are dumb questions, I haven't had a good excuse to dive into the log library yet.

No, nothing from boost_log_setup is core functionality. In fact, large binary size and optionality of that code was the reason why I separated it to another library. Aside from logging itself, Boost.Log provides support for reading logging configuration from files or streams. For the most part this consists of 3 parsers: filter parser, formatter parser and settings parser. The former two can be used as standalone components, without connection to the settings parser. So you basically can pass a string to the library and it returns a filter/formatter that you can call and use with the rest of the library. Now, these 3 parsers use Boost.Spirit and this makes them have lots of debug info, which makes them so large (see my reply to Antony in this thread). The problem worsens with the fact that the parsers are built both for char and wchar_t by default. One other part of boost_log_setup that takes space is the default filter/formatter factories that are instantiated for all fundamental types. These factories are invoked by the parsers to actually create the filters and formatters. Without them the user has to register every single attribute in the library (both filter and formatter factory), which would make it very inconvenient to use. Right now users only have to register their custom typed attributes. Anyway, this last part (default factories) I can make optional, and I think this will reduce binary size considerably. However, I don't think this can be done for 1.54. Regarding parsers though, I'm not sure there's anything I can do, but if I'd appreciate if any Boost.Spirit/Boost.Phoenix gurus would take a look at them and suggest how to tweak them. Regarding the build defaults, by default the library builds in its maximum configuration. I.e. it should just work by default. If you want to optimize (like, reduce binary size), you should disable the things you don't need. I believe this is the right approach and it allows to avoid puzzling users with unnecessary problems. Library configuration is described here: http://www.boost.org/doc/libs/1_54_0/libs/log/doc/html/log/installation/conf...