On Sat, May 27, 2017 at 1:51 PM, Isuru Fernando wrote:
> On Sat, May 27, 2017 at 4:46 PM, Erik Bray wrote:
>>
>> On May 27, 2017 11:13 AM, "Volker Braun" wrote:
>>
>> In fact, if we were to do some major changes to the build system we should
>> consider building on top of conda. In particular, w
On Sat, May 27, 2017 at 01:16:39PM +0200, Erik Bray wrote:
> All I'm proposing are some very *minor* changes that change little about
> how Sage is currently worked on, while still being a quality of life
> improvement, in a way.
Hi Erik.
that's great news.
and it sounds like the way to go, part
On Sat, May 27, 2017 at 4:46 PM, Erik Bray wrote:
> On May 27, 2017 11:13 AM, "Volker Braun" wrote:
>
> In fact, if we were to do some major changes to the build system we should
> consider building on top of conda. In particular, we shouldn't just crap
> arbitrary files into $SAGE_LOCAL during
On May 27, 2017 11:32 AM, "Jeroen Demeyer" wrote:
Otherwise it sets `$(inst_)` to a
> dummy file that always exists (this way any dependencies for that
> package are still satisfied, but the spkg is never actually
> built/installed).
>
Let me mention *why* I came up with this dummy file: even if
On May 27, 2017 11:13 AM, "Volker Braun" wrote:
In fact, if we were to do some major changes to the build system we should
consider building on top of conda. In particular, we shouldn't just crap
arbitrary files into $SAGE_LOCAL during build, but turn each package into
separate binary achive that
Otherwise it sets `$(inst_)` to a
dummy file that always exists (this way any dependencies for that
package are still satisfied, but the spkg is never actually
built/installed).
Let me mention *why* I came up with this dummy file: even if configure
detects that a Sage package is not needed, it
Have a look at spack as well, which is a package-manager. Although it's not
a single software application, it uses system packages when specified to
build a package.
http://spack.readthedocs.io/en/latest/build_settings.html
Isuru Fernando
On Sat, May 27, 2017 at 1:19 PM, Erik Bray wrote:
> On
In fact, if we were to do some major changes to the build system we should
consider building on top of conda. In particular, we shouldn't just crap
arbitrary files into $SAGE_LOCAL during build, but turn each package into
separate binary achive that then gets installed.
* Going back in the git
On May 26, 2017 23:49, "William Stein" wrote:
On Fri, May 26, 2017 at 6:01 AM, Erik Bray wrote:
[...]
> The extent and scope to which Sage "vendors" its dependencies, in the
> form of what some call "sage-the-distribution", is *not* particularly
> normal in the open source world. Vendoring *som
Another system that takes the Sage-like "distribution" approach, and is
worthwhile to have a look to see how they package things, is Macaulay2.
However, they have a serious technical reason for such an approach, as they
need compatibility with Boehm GC, and many libraries they need typically ha
On Fri, May 26, 2017 at 6:01 AM, Erik Bray wrote:
[...]
> The extent and scope to which Sage "vendors" its dependencies, in the
> form of what some call "sage-the-distribution", is *not* particularly
> normal in the open source world. Vendoring *some* dependencies is not
> unusual, but Sage does
Hi folks interested in Sage packaging,
Almost every time the topic comes up, I complain that it isn't easier
to use more system packages as both build- and run-time dependencies
of Sage. I'd like to make some progress on actually doing something
about that, and I have some ideas, but I'd like to
12 matches
Mail list logo
