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 >
