Hi Andrew.
some of this is confusing a lot...
On Sun, Apr 21, 2013 at 03:45:10PM -0700, R. Andrew Ohana wrote:
> 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).
>
> 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.
(of course files need to be regenerated in case dependencies change)
> So at some point a python module like module_list.py will have to be used,
> potentially generated.
somewhere there must be list of files/rules. i don't see why it must be
a *python module*. Makefiles would be probably less magic and more
transparent (is this another topic?). anyohow i don't see a link to
checking functionality.
checking for headers/libraries/availibility is done by the configure
script. it is meant to either break if something is missing or set paths
accordingly. cython/cythonize/gcc/whatever is called much later.
> > 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).
okay, so sage the program is not the sage executable. almost obvious :)
(2) does not contain the notebook. the notebook is a module (as it
should).
unrelated parts of src/bin should be moved to where they are needed.
> 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.
sage "the program" is not functional without either a software distribution or
sage "the distribution", so why bother? "a copy of sage" is not well
defined either. so no -- i don't see any complication in handling
modules as modules. there's virtually no overhead in modules, as sage
("the distribution") will always have to care about foreign modules.
> 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
the topic of the gsoc project is "make sage distribution friendly". this
forbids to add another extra layer that is of no use for distributions.
what you probably want to do, when you write "install all of \"sage as a
program\"" is install ("sage the distribution" minus "foreign
packages"). this is a legitimate goal, and should be implemented as
./configure --skip-foreign --enable-notebook && make install
(details may vary) within a tarball of sage "the distribution".
why would you want to install sage "the program" without the ability to
install other modules? why would you want to use the toplevel
("distribution") configure script to do this? there will always be
another package that makes even less sense to merge into the
distribution tarball.
> --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
make targets without configurability are of no use (for distributions).
if packaging sage (which means dissecting what you propose to merge)
remains reserved for sage-experts (as Tim Abbott probably is), all this
helps nobody.
to be distribution friendly, sage (the distribution) needs to use the
same interfaces to its modules that other distributions need. otherwise,
before the next release, nobody will care a lot about it, and
no distribution will be able to catch up.
sage already was modular in that sense, before the git transition
started. all that was missing, was a build system for sagelib and
sage-python (this is where i ignorantly started my first proposal).
switching to git is a great idea. if submodules/externals are to
complicated to use, subdirectories are less meaningful but still great
in seperating parts.
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.
