On Tue, Apr 12, 2016 at 2:35 AM Erik Bray <erik.m.b...@gmail.com> wrote:
> On Mon, Apr 11, 2016 at 7:49 PM, Ian Henriksen wrote: > > With regards to the dllexporting/dllimporting of things: given that > public > > declarations > > are already designed to export things through the shared object > interface, > > we may > > as well fix the current setup to export the right things. It's a bad > design > > that > > probably ought to be deprecated or at least documented better so people > know > > not > > to use it unless their case actually requires sidestepping best > practices. > > On the > > other hand, it's also a supported interface, so there's value in "fixing" > > it. > > > > I think the best way to do that is the following: > > - mark public symbols as dllimport unless a given (module specific) > > preprocessor > > define is set. > > - people using the public header outside of the module exporting the > symbols > > should not have to set the define at all. > > - people using the public header to compile other source files that are > > linked in to > > the same Python module should set the preprocessor flag for that module. > > That's the approach I was trying to take originally, yes. But I think > it's a burden to require developers to set that preprocessor > flag--instead it should happen automatically, (or not at all, with > preference instead for using a completely separate header for > intra-module use). > > > On top of that, at some point we still need to fix our api and public > > headers so that > > they still work when included into the translation unit for the main > > Cython-generated > > c/cpp file. This use-case should just forward-declare everything since > the > > needed > > symbols are all defined later on in the Cython module. Since static > > variables > > cannot be forward declared in C, this will require that api declarations > use > > shared > > object local symbols or that the main generated c/cpp file use some ifdef > > guards > > when it initializes the various pointers in question. > > Sounds good--I see no problem with this. > > > As far as making an additional header goes, I personally prefer the extra > > preprocessor define. On the other hand, if people think an additional > header > > is > > easier to use, then why not make it do something like > > > > #define USE_DLLEXPORT_NOT_DLLIMPORT_FOR_PARTICULAR_MODULE > > #include <the_original_public_header_with_improved_defines.h> > > > > I think, that'd cover all the use cases better. > > That would be fine too and reduce duplication. I think such a header > should still be generated though and it should be documented when to > use which header. > > After thinking this over a bit more, it seems like we're discussing things that really have more to do with the API chosen for a particular module than anything else. Maybe these options should all be made available as Compiler flags to Cython instead. As far as I can tell there are two separate options here: - Whether to provide distinct headers for defining the needed importing functionality, or declaring it as extern - Whether to make the preprocessor define flag for a given module's header work as an opt-in or an opt-out for defining the symbols needed to import and use the module. (numpy's headers use an opt-out system. DyND doesn't currently have this set up all of the way, but we'd like to use an opt-in model for working with our headers). Thoughts? Best, -Ian
_______________________________________________ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
