Just adding my opinion here as I have been following this thread. Would it be possible to have both the .so library and header only options available or is it a strictly 'this-or-that' scenario?
Regards, Charles On Wed, Aug 17, 2016 at 2:53 PM, Karl Rupp <r...@iue.tuwien.ac.at> wrote: > 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 >
------------------------------------------------------------------------------
_______________________________________________ ViennaCL-devel mailing list ViennaCL-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viennacl-devel
