[oops, resend: forgot the sage cc. sorry] Hi Pablo,
[ cc-ing sage-dev again, since someone there may have better things to say than me ] On 2/24/07, Pablo De Napoli <[EMAIL PROTECTED]> wrote: > Fernando, it my opinion, it is not true that this way, things > will "just work" > > For example, I've tried to compile sarge-2.4.1 on my system and it didn't > compile because the compilation of pari-2.3.1cvs failed (as gcc-2.4.1 > seems not to understand the -rpath option. ) > > [I've already reported this on the Sage forums] I didn't say that the system was perfect. Of course, problems do occur, but in my experience, the sage build system is remarkably robust. And when (not if) problems arise, William has been very responsive (he knows the build system better than anyone). So does it have failure cases? Sure. But let me put it differently: the number of build problem reports on the sage lists is /vastly/ lower than that on the scipy list, and SAGE is /enormously/ bigger than scipy. But scipy tries to build as a library, in the user's environment, allowing users to specify their own ATLAS/BLAS and compiler choices, etc. Despite heroic efforts by the scipy build people, not a week goes by without someone running down endlessly detailed threads with obscure build problems. In /my/ experience, the situation for SAGE is a lot better. Not perfect, but better (and yes, at the price of not being 'included' in its environment but rather walled off). > However, I do have pari-2.3.1 already installed in my system! > (compiled by using an ebuild from Gentoo) > > If you want things to "just work" for end-users, is inded provide > ready- to-use binaries. Most end-users are quite afraid of > compiling the source code of anything from the sources. Which they do: http://modular.math.washington.edu/sage/download.html where they list: # Binaries: OS X, Microsoft Windows, Linux 32-bit, and Linux 64-bit. > Perhaps.you could provide a live CD which they do (same location): # Live CD: ISO and VMware image > But making Sage more modular would mean certainly make it more > friendly for developers (and more developers, means that you code could > evolve faster, with more contributions). As I mentioned, there is interest in doing this. Help would be, I'm sure, welcome. But it is a non-trivial problem and with limited resources, not everything gets done at the same time. > [ For example, this is the reason why the people of X.org decided > to split the X source , read their rationale at > > http://wiki.x.org/wiki/ModularizationProposal] This is a different situation: X was monolithic in a very different sense than SAGE is. SAGE may be 'walled off' inside the SAGE_ROOT build directory and environment, but in there, its structure is highly modular and well compartmentalized. The situation is, on technical terms, /completely/ different from that of X. Please don't confuse the two, it adds no value to this discussion and only would serve to start propagating a misrepresentation of the structure of SAGE. Yes, it would be nice to have a more modular and 'pluggable' build for SAGE and any help on that front will be well received. But comparing it to the old X is inaccurate. Regards, f --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
