On Tuesday 10 February 2015 22:52:18 Jon A. Cruz wrote: > On 02/10/2015 10:33 PM, Thiago Macieira wrote: > > Before I can offer suggestions, I'd like to ask what our .so / .dll file > > outputs> > > shall be. Will we have: > > a) one DLL for the C SDK, one for the base discovery & connectivity, one > > (or> > > more) for service? > > > > b) one DLL for the C SDK and one for the C++ bits? > > c) one DLL for everything? > > Ooh. This is going to be a bit more problematic if DLLs need to be > produced. Doing DLLs of the C++ parts is going to be extremely > problematic (due to the OS and tool conventions on Windows). There also > generally would be a need to support interesting combinations of static > & dynamic on many fronts (static library linked to dynamic runtime, > static library linked to static runtime...)
Hi Jon Let's not get into the ABI problem with Windows compilers right now. I know that topic more than I'd care to admit... when we get to it, I'll lend my experience so we create proper DLLs. For now, please understand it as the principle of the thing and think of .so files on Linux. I wrote "DLL" because I expected people to recognise the concept more easily than "SO" or "shared object". > So we might need to split the C into one or more DLLs and the C++ into > one or more static libs. Fair enough, but I'd like to know what that split should be. I'm asking this because I'd like the directory structure to match the target libraries. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
