On Wed, Aug 19, 2015 at 1:22 AM, Nathaniel Smith <n...@pobox.com> wrote:
> On Tue, Aug 18, 2015 at 4:15 PM, David Cournapeau <courn...@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
>
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
