[Numpy-discussion] reorganizing numpy internal extensions (was: Re: Should we drop support for "one file" compilation mode?)

Nathaniel Smith njs at pobox.com
Thu Oct 8 03:10:17 EDT 2015


On Tue, Oct 6, 2015 at 12:19 PM, Charles R Harris
<charlesr.harris at gmail.com> wrote:
>
>
> On Tue, Oct 6, 2015 at 1:04 PM, Nathaniel Smith <njs at pobox.com> wrote:
[...]
>> Anyway, it sounds like we agree that the next step is to merge
>> multiarray and umath, so possibly we should worry about doing that and
>> then see what makes sense from there :-).
>>
>
> What about removing the single file build? That seems somewhat orthogonal to
> this discussion.

We seem to also have consensus about removing the single file build,
but yeah, it's orthogonal -- notice the changed subject line in this
subthread :-).

> Would someone explain to me the advantages of the single
> file build for static linking, apart from possible doing a better job of
> hiding symbols? If symbols are the problem, it there not a solution we could
> implement?

Hiding symbols is the only advantage that I'm aware of, and as noted
in the other thread there do exist other solutions. The only thing is
that we can't be absolutely certain these tools will work until
someone who needs static builds actually tries it -- the tools
definitely exist on regular linux, but IIUC the people who need static
builds are generally on really weird architectures that we can't test
ourselves. Or for all I know the weird architectures have finally
added shared linking and no-one uses static builds anymore. I think we
need to just try dropping it and see.

-n

-- 
Nathaniel J. Smith -- http://vorpus.org



More information about the NumPy-Discussion mailing list