On Sun, Apr 21, 2013 at 6:05 AM, Felix Salfelder <fe...@salfelder.org>wrote:
> a configure script would locate headers depending on the flags
> (--with-ntl=/here/or/there ...), does a check (optional) and then sets
> CFLAGS/wheteverFLAGS accordingly. Cython is used to write .c out of
> .pyx, i don't see why/how it could care about configure options.
>
> (just to be sure: what does it have to do with a dependency tree?)
>
More the point is that you do not want to directly call the terminal
command for cython -- rather you want
to call cythonize on a python list of modules, as it regenerates c files if
the corresponding pyx file is touched or if any file that the pyx depends
on is touched. Moreover, it provides extra functionality (such as cycache:
ccache for cython) that we will likely want to take advantage of.
So at some point a python module like module_list.py will have to be used,
potentially generated.
> 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.
>
> sage as a program is in <git-transition-repo>/src/bin. there used to be
> a sage-scripts.spkg. notebook is another package...
> yes, these need also be considered modules/packages.
>
By "sage as a program" is almost everything under src (some scripts in
src/bin are only needed for distribution purposes).
> 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.
>
> agreed.
>
> > 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).
>
> in the end, sage ("the distribution"), i.e. the top-level-stuff, must
> take care of building/installing the modules in the right order. having
> one module that builds another undermines this logic.
>
As a person who frequently compiles software from source I have a big
objection to breaking up the configuration of "sage as a program" into
multiple components, it complicates the process for someone who has all the
dependencies and just wants to build a copy of sage. By default I think
that `./configure && make && make install` should setup a makefile that
will build and install all of "sage as a program". If you want more
modularity you could have an extra configure flag
--with-csage=PATH uses csage at path instead of building its own copy
of csage
and separate make targets for installing the various components
make install_bin
make install_lib
make install_extcode
make install_csage
make install_doc
(and then corresponding build targets for those that need them)
--
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.
