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
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
On Tue, Aug 18, 2015 at 9:07 PM, Charles R Harris <charlesr.harris@gmail.com
wrote:
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 NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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, 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
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
participants (3)
-
Charles R Harris -
David Cournapeau -
Nathaniel Smith