Hi Dmitriy, > We could (and probably should?) add such a convenience header file > at the expense of increased compilation times (and reduced > encapsulation of source code against compiler issues). > > > +1 on single header! :)
thanks for the feedback: https://github.com/viennacl/viennacl-dev/issues/196 > Ultimately, this all boils down to fighting limitations of the > current header-only source code distribution model. > > > FWIW, if our opinion matters, actually, header-only is one of the things > we like very much. It means we don't have to redistribute any > executables, everything already is included in our jars, everything that > we use and need (and only it) is already generated for us by javacpp. > This is one of the most valuable features about ViennaCL in my opinion. > It is very hard to get customers to install yet-another libX.so on their > clusters. I agree that additional libraries on clusters can be tricky at times... > But header-only, template-based code solves > > (1) we include everything we need in jar (no extra infra requirement) > (2) we include only that we actually support/use (lightweight, slim > application size requirement) > > these are very valuable for flink/spark type of applications. Which is > what we are. > > I know that you have plans to generate a .so lib with apparently > non-object API, but for apache mahout the OAA api with header-only > requirement is super optimal. (at least I have a high hope you won't > _force_ us to redistribute an .so(s) in the future releases :) ) Will a static library suffice for your purposes? I'm not an expert on releasing .jar packages, but I'd expect that a static library could offer similar advantages to an header-only approach. Best regards, Karli ------------------------------------------------------------------------------ _______________________________________________ ViennaCL-devel mailing list ViennaCL-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viennacl-devel
