On Mon, Apr 11, 2016 at 7:49 PM, Ian Henriksen
wrote:
> On Mon, Apr 11, 2016 at 7:46 AM Erik Bray wrote:
>>
>> On Mon, Apr 11, 2016 at 2:51 PM, Nathaniel Smith wrote:
>> > On Apr 11, 2016 04:18, "Erik Bray" wrote:
>> >>
>> >> On Fri, Apr 8, 2016 at 5:49 PM, Nathaniel Smith wrote:
>> >> > Can y
On Mon, Apr 11, 2016 at 12:36 PM Ian Henriksen <
insertinterestingnameh...@gmail.com> wrote:
> On Mon, Apr 11, 2016 at 11:50 AM Ian Henriksen <
> insertinterestingnameh...@gmail.com> wrote:
>
>> To answer the original question about define macros, it appears that the
>> canonical
>> way to pass pr
On Tue, Apr 12, 2016 at 2:35 AM Erik Bray 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
>
On Tue, Apr 12, 2016 at 2:35 AM Erik Bray wrote:
> On Mon, Apr 11, 2016 at 7:49 PM, Ian Henriksen
> wrote:
> > That aside, I agree with Nathaniel that exporting public declarations as
> a
> > part of the
> > shared object interface was a design mistake. That aside, however, using
> an
> > api
>
On Tue, Apr 12, 2016 at 10:27 AM, Jeroen Demeyer wrote:
> On 2016-04-12 10:16, Erik Bray wrote:
>>
>> That said, I
>> think it makes more sense for cythonize() to read the distutils
>> options from the C source instead of the Cython source, though in
>> practice I don't know if it's a worthwhile c
On Mon, Apr 11, 2016 at 7:49 PM, Ian Henriksen
wrote:
> That aside, I agree with Nathaniel that exporting public declarations as a
> part of the
> shared object interface was a design mistake. That aside, however, using an
> api
> declaration lets you get equivalent results without exposing anythi
On 2016-04-12 10:08, Erik Bray wrote:
OSX issues aside, I was under the impression that this is needed for
cysignals in particular.
No. cysignals is complicated, but it doesn't need dynamic linking to
Python modules (.so files). It does need "internal" linking: it needs to
link a non-Cython-g
On 2016-04-12 10:16, Erik Bray wrote:
That said, I
think it makes more sense for cythonize() to read the distutils
options from the C source instead of the Cython source, though in
practice I don't know if it's a worthwhile change or not.
I don't quite get what you mean. The C file is only read
On Mon, Apr 11, 2016 at 8:36 PM, Ian Henriksen
wrote:
> On Mon, Apr 11, 2016 at 11:50 AM Ian Henriksen
> wrote:
>>
>> To answer the original question about define macros, it appears that the
>> canonical
>> way to pass preprocessor defines through distutils is to use the
>> define_macros
>> keywo
On Mon, Apr 11, 2016 at 7:38 PM, Jeroen Demeyer wrote:
> On 2016-04-11 15:23, Erik Bray wrote:
>>
>> In this case I really do want the symbol "hello" to be
>> exported by the DLL, as well as be understood between translation
>> units making up the same library.
>
>
> Are you really sure that you w
On Mon, Apr 11, 2016 at 11:50 AM Ian Henriksen <
insertinterestingnameh...@gmail.com> wrote:
> To answer the original question about define macros, it appears that the
> canonical
> way to pass preprocessor defines through distutils is to use the
> define_macros
> keyword when constructing your Ex
On Mon, Apr 11, 2016 at 7:46 AM Erik Bray wrote:
> On Mon, Apr 11, 2016 at 2:51 PM, Nathaniel Smith wrote:
> > On Apr 11, 2016 04:18, "Erik Bray" wrote:
> >>
> >> On Fri, Apr 8, 2016 at 5:49 PM, Nathaniel Smith wrote:
> >> > Can you give a tiny concrete example? My questions are basic enough
>
On 2016-04-11 15:23, Erik Bray wrote:
In this case I really do want the symbol "hello" to be
exported by the DLL, as well as be understood between translation
units making up the same library.
Are you really sure that you want this? I doubt that this is supported
on OS X: on OS X, there are tw
On Apr 11, 2016 06:23, "Erik Bray" wrote:
>
> On Mon, Apr 11, 2016 at 2:51 PM, Nathaniel Smith wrote:
> > Now, back to your example: Here the caller and callee are both compiled
into
> > the same shared library, so you don't want dllexport/dllimport at all,
you
> > just want a shared-library-inte
On Mon, Apr 11, 2016 at 2:51 PM, Nathaniel Smith wrote:
> On Apr 11, 2016 04:18, "Erik Bray" wrote:
>>
>> On Fri, Apr 8, 2016 at 5:49 PM, Nathaniel Smith wrote:
>> > Can you give a tiny concrete example? My questions are basic enough that
>> > I
>> > feel like I'm missing something fundamental :
On Mon, Apr 11, 2016 at 2:51 PM, Nathaniel Smith wrote:
> Now, back to your example: Here the caller and callee are both compiled into
> the same shared library, so you don't want dllexport/dllimport at all, you
> just want a shared-library-internal symbol, which as we see is much easier.
Sorry,
On Apr 11, 2016 04:18, "Erik Bray" wrote:
>
> On Fri, Apr 8, 2016 at 5:49 PM, Nathaniel Smith wrote:
> > Can you give a tiny concrete example? My questions are basic enough
that I
> > feel like I'm missing something fundamental :-)
>
> Yes, I think you might be missing something, but I'm not sure
On Fri, Apr 8, 2016 at 5:49 PM, Nathaniel Smith wrote:
> Can you give a tiny concrete example? My questions are basic enough that I
> feel like I'm missing something fundamental :-)
Yes, I think you might be missing something, but I'm not sure exactly
where. In the issue I provided a tiny exampl
Can you give a tiny concrete example? My questions are basic enough that I
feel like I'm missing something fundamental :-)
My first question is why you even need this, since AFAIK there are no cases
where it is correct to have a cython module dllexporting symbols that
appear in header files. This
Hi all,
I'd like to call attention to an issue I've been looking into for the
past couple days:
https://github.com/cython/cython/pull/360
To summarize the discussion, when building DLLs for Windows, functions
that should be exported by that DLL must be marked
__declspec(dllexport) in their decla
20 matches
Mail list logo
