On Wed, Aug 19, 2015 at 1:22 AM, Nathaniel Smith <njs@pobox.com> wrote:
On Tue, Aug 18, 2015 at 4:15 PM, David Cournapeau <cournape@gmail.com> wrote:
> If everybody wants to remove bento, we should remove it.

FWIW, I don't really have an opinion either way on bento versus
distutils, I just feel that we shouldn't maintain two build systems
unless we're actively planning to get rid of one of them, and for
several years now we haven't really been learning anything by keeping
the bento build working, nor has there been any movement towards
switching to bento as the one-and-only build system, or even a clear
consensus that this would be a good thing. (Obviously distutils and
numpy.distutils are junk, so that's a point in bento's favor, but it
isn't *totally* cut and dried -- we know numpy.distutils works and we
have to maintain it regardless for backcompat, while bento doesn't
seem to have any activity upstream or any other users...).

So I'd be totally in favor of adding bento back later if/when such a
plan materializes; I just don't think it makes sense to keep
continuously investing effort into it just in case such a plan
materializes later.

> Regarding single file builds, why would it help for static builds ? I
> understand it would make things slightly easier to have one .o per
> extension, but it does not change the fundamental process as the exported
> symbols are the same in the end ?

IIUC they aren't: with the multi-file build we control exported
symbols using __attribute__((visibility("hidden")) or equivalent,
which hides symbols from the shared object export table, but not from
other translation units that are statically linked. So if you want to
statically link cpython and numpy, you need some other way to let
numpy .o files see each others's symbols without exposing them to
cpython's .o files,

It is less a problem than in shared linking because you can detect the conflicts at linking time (instead of loading time).


and the single-file build provides one mechanism
to do that: make the numpy symbols 'static' and then combine them all
into a single translation unit.

I would love to be wrong about this though. The single file build is
pretty klugey :-).

I know, it took me a while to split the files to go out of single file build in the first place :)

David
 

-n

--
Nathaniel J. Smith -- http://vorpus.org
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion