[Bf-committers] Boost dependency

Mon Nov 5 18:29:28 CET 2012

Brecht,

We need to define here which else libraries we're using for release builds.
For as long OIIO, OSL are used you can not avoid maintaining boost builds
for the release. On linux it's really easy to compile, on windows doubt
it's more tricky than building ffmpeg or collada. Zapping boost wouldn't
save so much time. You also don't need to update it so much often. So can
not see point here.

Further, if you already need boost for release build, why don't use stuff
from it in cases it indeed helps you?

In my opinion, it's ok for as long as you can disable boost and have
blender build with smaller subset of features. Same goes to sdl, carve and
other libraries as well.

On Mon, Nov 5, 2012 at 11:07 PM, Brecht Van Lommel <
brechtvanlommel at pandora.be> wrote:

> 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
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>

-- 
With best regards, Sergey Sharybin