[Numpy-discussion] Proposal to remove the Bento build.

[Charles R Harris]

Hi All,
.
I'm bringing up this topic again on account of the discussion at
https://github.com/numpy/numpy/pull/6199. The proposal is to stop (trying)
to support the Bento build system for Numpy and remove it. Votes and
discussion welcome.

Along the same lines, Pauli has suggested removing the single file builds,
but Nathaniel has pointed out that it may be the only way to produce static
python + numpy builds. If anyone does that or has more information about
it, please comment.

Chuck

[David Cournapeau]

If everybody wants to remove bento, we should remove it.

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 ?

David

Post by Charles R Harris
Hi All,
.
I'm bringing up this topic again on account of the discussion at
https://github.com/numpy/numpy/pull/6199. The proposal is to stop
(trying) to support the Bento build system for Numpy and remove it. Votes
and discussion welcome.
Along the same lines, Pauli has suggested removing the single file builds,
but Nathaniel has pointed out that it may be the only way to produce static
python + numpy builds. If anyone does that or has more information about
it, please comment.
Chuck
_______________________________________________
NumPy-Discussion mailing list
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Nathaniel Smith]

Post by David Cournapeau
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.

Post by David Cournapeau
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, 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 :-).

-n

[David Cournapeau]

Post by Nathaniel Smith

Post by David Cournapeau
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.

Post by David Cournapeau
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

Post by Nathaniel Smith
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

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