On Sun, Apr 21, 2013 at 4:59 AM, Felix Salfelder <fe...@salfelder.org>wrote:
> Hi Andrew. > > thanks for your comments. > > On Sun, Apr 21, 2013 at 03:47:36AM -0700, R. Andrew Ohana wrote: > > When you say "write/exchange the build systems for the core parts (c_lib, > > python-sage, extcode...)" what exactly is your goal? > > currently, the modules c_lib and sage-python etc. don't have a dedicated > build systems goal is, to create build systems for these modules, taking > over the role of ../setup.py > > > I don't think it makes much sense completely rewriting the > setup.py/modules, > > especially in Makefile (as it sounds like you might have been thinking). > > it's not completely rewriting, think of it as modularization/conversion > (while adding checks for availability/headers/libraries and the like). > Ah, yes, I see your point. One suggestion then is to maybe think about adding such checking functionality to Cython directly (since it already computes the entire dependency tree, just doesn't have any of the necessary checks). > > If you are looking for making an autotools based build system (here > > assuming part of your goal for (1) is to make a single configure for all > of > > "sage as a program") > > no. (1) is not about a top-level build system. > (a top-level build system is another story and relies on configurable > modules. lets discuss it!) > No, I did not me a top-level build system -- as I see it there are three embedded levels of sage: 1) sage as a python library 2) sage as a program (i.e. the terminal command prompt/notebook) 3) sage as a distribution. Currently you can only get to 1 and 2 as components of 3, and the goal of this project is to make it more modular so as to be able to get at 1 and 2 outside of 3. To me it makes the most sense to have a single configure script for 2 (as a set), with a configure flag to just build 1, the python library (if so desired). A top-level configure script (from how take people to use the term), would be a configure script for 3. > > then I would suggest just calling `python setup.py > > build` and `python setup.py install` in the appropriate places. > > setup.py doesnt do what is needed, when packaging for a distribution. > writing a script that calls "setup.py install" doesnt make > that module distributable either. > > it might make sense to call distutils from an autotools Makefile (at > least for the python part). I guess I was a bit unclear, this is what I meant. looking at how setup.py works around > dependencies and implements parallelization, i doubt anyone will > seriously regret the conversion. > > regards > felix > > -- > You received this message because you are subscribed to the Google Groups > "sage-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-devel@googlegroups.com. > Visit this group at http://groups.google.com/group/sage-devel?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- Andrew -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
