[Bf-committers] Boost dependency

Mon Nov 5 18:07:52 CET 2012

Hi,

We added Boost mostly because OpenImageIO and OSL depend on it. It's
used in Cycles itself too but this can be removed, however given that
it depends on OIIO and OSL anyway it seems a bit pointless. Not sure
if there is any practical way in which it could be removed unless we
remove those libs too. For Mac and Windows builders the libs are in
svn along with all the others, so there's no problem. For Linux all
distributions have them as packages so they're as easy to install as
other dependencies.

We could however strip out unnecessary header files in the Mac and
Windows lib/ directory, to make the svn download smaller.

Anyway, I think you can indeed abuse boost, but it also contains a lot
of stuff that is quite useful and makes c++ code cleaner. I don't see
anything wrong with our audio library using boost::shared_ptr.
Audaspace can be disabled for minimal builds, and if you want a
complete build you need Boost anyway. I think it's reasonable to
expect a minimal Blender to work without Boost, but don't see much
reason to not allow it in optional libraries like this.

In my opinion the main reason to not use Boost is that it's extra work
for platform maintainers or builders. That's weighted against the work
that would be needed to implement our own version of this
functionality and do the same in external libraries that we use. I
don't really understand the bloat argument that is used often, if
there's something in it that you don't need you don't have to use it,
and it won't add to the Blender binary size. I also don't see it
slowing down builds much.

Brecht.

On Mon, Nov 5, 2012 at 6:00 PM, Erwin Coumans <erwin.coumans at gmail.com> wrote:
> It would be interesting to what you are using from boost.
>
> Containers (replacements for vector, list, hashmap/unordered) doesn't seem enough for all those megabytes dependency. In our Bullet library they are just a few files. A threading abstraction or smart pointer isn't convincing either.
>
> Pointing to other large or templated libraries that are"just as bad or worse" is not a good argument either.
>
> My few cents,
> Erwin
>
> Sent from my iPhone
>
> On Nov 5, 2012, at 8:22 AM, Lukas Tönne <lukas.toenne at gmail.com> wrote:
>
>> I agree with Sergey. Boost certainly looks huge in downloads for
>> coders, but AFAIK when linking static libraries it actually strips not
>> just unused libraries but even all unused *symbols* from a library.
>> Since we're using only a small subset of boost it does not increase
>> the binary size more than what would be needed if we tried to
>> implement all those features ourselves.
>>
>> It's true that using templates excessively can lead to
>> incomprehensible code. However, the typical use case for templates is
>> generic container classes (lists, hash, etc.), for which there is
>> usually just one template parameter and that is really not so hard to
>> understand. Code can be further simplified by making typedefs for such
>> templated classes, so the template only has to be used in one place:
>>
>> typedef boost::unordered_map<Blah> BlahMap;
>>
>> Some of the features we're using from boost are really quite complex
>> (e.g. boost::unordered [1]). Implementing these types on our own would
>> be just stupid IMHO, especially if you want to avoid templates at all
>> cost and have to do that for every type (or even do it C style with
>> untyped void*, which is even more confusing and less efficient).
>>
>> I don't see the advantage in kicking out boost.
>>
>> [1] http://www.boost.org/doc/libs/1_51_0/doc/html/unordered.html
>>
>> On Mon, Nov 5, 2012 at 4:47 PM, Sergey Sharybin <sergey.vfx at gmail.com> wrote:
>>> Boost is only 50Mb, and it consists of lots of smaller libraries (like 28
>>> libs) and we're only using few of them (like 3 or 4). This libs are getting
>>> stripped further when linking blender. We're also using some header-based
>>> classes from boost, but that's not so much i guess.
>>>
>>> Not sure why portability would be an issue -- boost is used by lots of
>>> other applications and it's nicely supported on all platforms we're
>>> compiling blender for
>>>
>>> We're not using so much templates from boost atm. There are much more
>>> templates in eigen library. And much more templates in libmv/ceres. But
>>> that's not issue there -- without templates here the could would have been
>>> completely unmanageable. Be my guest to make it templateless with the same
>>> readability.
>>>
>>> And i'm still not sure what's the issue here? We're already using boost in
>>> quite a lot of areas and not sure why don't use it in other areas?
>>>
>>> P.S. If you're worried about size let's switch to discussing dependency
>>> from SDL, which we're using as one of possible backends for audio. SDL is
>>> like 150-200Mb of dependencies we're actually using (only helps that it's
>>> possible to link dynamically against SDL and keep it working) -- it
>>> includes SDL itself, ALSA which is used by SDL and so on.
>>>
>>>
>>> On Mon, Nov 5, 2012 at 9:30 PM, Ton Roosendaal <ton at blender.org> wrote:
>>>
>>>> Hi,
>>>>
>>>> Can I get advice from the c/c++ devs here if Boost is going to be a
>>>> default dependency now?
>>>> It is currently possible to disable Boost by excluding some libs (like for
>>>> mini blender compiles).
>>>>
>>>> I'm concerned about portablity too. And from my limited POV any library
>>>> takes 200 MB diskpace is suspicious!
>>>>
>>>> Next to that - we do serious attempts to keep code readable in Blender.
>>>> Heavy use of templates can lead to constructions nobody will ever be able
>>>> to debug. It's a common issue with C code too - but in C++ hacking even
>>>> more. In other developer environments people agree together on sticking to
>>>> only a limited subset of all C++ features for that reason.
>>>>
>>>> (Our audio library now uses Boost, that's the reason)
>>>>
>>>> Laters,
>>>>
>>>> -Ton-
>>>>
>>>> ------------------------------------------------------------------------
>>>> Ton Roosendaal  Blender Foundation   ton at blender.org    www.blender.org
>>>> Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands
>>>>
>>>> _______________________________________________
>>>> Bf-committers mailing list
>>>> Bf-committers at blender.org
>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>>
>>>
>>>
>>>
>>> --
>>> With best regards, Sergey Sharybin
>>> _______________________________________________
>>> Bf-committers mailing list
>>> Bf-committers at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers