On Mon, Apr 22, 2013 at 11:34:05AM +0200, Tobias Hansen wrote:
> On 04/22/2013 11:14 AM, Jeroen Demeyer wrote:
> > [..]
> >libcsage means nothing without the Sage Python library, the
> >Sage Python library requires libcsage and the scripts make no sense
> >without Sage.
(see the other posts about why this is not entirely correct)
> It seems to me these three things belong into a Debian source
> package together and Sage should provide configure, build and
> install targets for them together (don't know if real configure
> script/makefile or a script invoking multiple other builds). The
> Debian source package would split the resulting files into binary
> packages python-sage, libsagec etc. which is a standard thing we do
> for most large projects we package in Debian.
i agree that it the contents of <git-transition-repo>/src could make one
debian source package. this is what Andrew calls sage ("the program").
a common build system for these would still break gentoo and include
sage-scripts which i think should be moved (completely/partly?) to sage
("the distribution").
also <gtr>/src contains more than just sage-scripts (src/bin),
sage-python (src/sage) and libcsage (src_c/lib). namely ext, doc and
mac-app. finally i expect even more modules to populate src/ so i'd like
to face it and write a build system for each of them (whether or not
sage ("the file server") provides them as seperate tarballs).
why?
0 simple structure, no exceptions
1 to keep build systems small and maintainable
2 to keep debian/rules simple and maintainable
3 to make gentoo happy (libc and sage-python issue)
4 to keep modules apart, painlessly add more (non-foreign) modules
5 to make sage ("the distribution") simple
6 to keep the directory structure
7 to support other kinds of distribution
details
0 exceptions are bad, and need someone who understands them
1 less checks, clear context, easier to write/read/debug, also for
non-experts
2 one build process for each package, clear distinction of targets,
different DESTDIRs
3 gentoo is weird, but why not?
4 some modules are unrelated, believe it or not.
importing sage-notebook into src/ (as proposed by Jeroen) wouldn't
require any changes to the configure logic.
5 sage ("the distribution") is modular wrt to the foreign packages. it
shouln't treat parts different depending on where the source resides.
a --skip-<thisandthat> is easier if every module is a module.
6 not changing the directories in src/ will definitely not break the
current build. this makes sense, because it's not complete yet.
7 you can *never* know which module of sage may be useful to someone for
some reason or other
so if the outcome is one module too many, a merge is trivial. the other
direction is certainly not.
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.
