There is one thing you could do, depending on which parts of Boost you need. Boost has a tool to extract only the headers you actually need and puts the extracted declarations into a custom namespace. If your dependencies are header-only, you can include those bits in the Ignite sources. That way, users won't have to install Boost, and it avoids version mismatch and DLL hell.
-- Brane On 20.05.2015 15:53, Yakov Zhdanov wrote: > Brane, the API has already been designed. In the best case all > functionality available in Java should be available in non-Java stuff (if > there are no technology limitations). I would not care about compile time - > Boost increases it, of course, but does not make compilation infinite. > Functionality, stability and developer convenience seem to be more > important. > > GridGain had its CPP stuff using Boost with ~4-5 min compilation on rather > weak machine. > > However, given that client will be completely reapproached and should be > less complex I would think whether we need any third party library at all. > > --Yakov > > 2015-05-20 12:27 GMT+03:00 Branko Čibej <br...@apache.org>: > >> On 20.05.2015 09:40, Vladimir Ozerov wrote: >>> This is not about resulting size of our lib. Moreover, we will not >>> statically link it to Ignite because in this case users will have >> troubles >>> when using both Boost and Ignite simultaneously. >>> The problem is that if we use Boost, we will force users to have it on >>> their machines during both build-time and runtime. And Boost is known to >>> have dready dependencies between their modules. So if we use only >>> concurrency module it might lead to transitive dependencies to lots other >>> ones. >> Using any part of Boost also increases compile times dramatically >> because if its inter-module dependencies and its heavy usage of template >> programming. >> >> >> The first step is to design an API, before deciding on a helper library, >> which you may not even need. Talking about Boost or TBB or whatnot >> before you even know what kind of features you need to implement your >> API is, to put it mildly, just crazy. >> >> Real Programmers do not download 11 jars to use one external method ... >> >> -- Brane >>
