Adding M4 as standard package

[Jeroen Demeyer]

How do you guys feel about adding a GNU M4 package? MPIR requires M4,
also PPL with its C interface (see #12672) requires a recent version of
M4. This would add about 1.2 MB to the Sage source distribution.

[Dima Pasechnik]

Are there any non-exotic systems where a good M4 version is not provided?

[Julien Puydt]

Le mercredi 20 juin, Dima Pasechnik a écrit:

> Are there any non-exotic systems where a good M4 version is not
> provided?

win32 -- nothing is provided... and non-exotic (yet).

Snark on #sagemath

[Volker Braun]

The minimal required version, GNU M4 1.4.5, was released in 2006. Are there still people using a 6-year old Mac to compile Sage? Does it have enough memory to build the 2012 developer guide? ;-)

[Jeroen Demeyer]

On 2012-06-20 11:13, Dima Pasechnik wrote:
> Are there any non-exotic systems where a good M4 version is not provided?

Depends on your definition of "non-exotic". Some versions of Solaris
(at least, the Skynet machine "mark") don't have it either.

But then again, there is a precedent: we are shipping iconv, which also
exists on all non-exotic systems and it's 3 times larger than m4 would be.

[Dima Pasechnik]

the only known working way to install and run Sage on win32 does not need M4 :–)  

Realistically, if cygwin ever reaches a state when Sage will build and run on it, M4 is certainly

there and new enough.

Snark on #sagemath

[Volker Braun]

The Skynet machine "mark" doesn't have it shipped with. Neither came it out of the box with a compiler that is able to compile Sage. I think at one point we'll have to live with the fact that some exotic architectures require the user to first install a semi-recent toolchain. Or install versions of software that the vendor isn't able or going to fix, see the recent Mandrake bash horror story. 

The first priority should always be to support *current* systems. Top priorities should probably include Ubuntu 12.04 x86_64 and OSX 10.7 binaries / testing.

[Jeroen Demeyer]

On 2012-06-20 14:49, Volker Braun wrote:
> The first priority should always be to support *current* systems. Top
> priorities should probably include Ubuntu 12.04 x86_64 and OSX 10.7
> binaries / testing.

Obviously yes, but if we can support older systems with minimal effort
and minimal disturbance for other systems, why not do this?

[Volker Braun]

I'm not totally opposed to adding M4, I just think its a better use of your time to tell the 3 remaining OSX 10.4 users that they need to first compile their own M4.

[Jeroen Demeyer]

On 2012-06-20 15:04, Volker Braun wrote:
> I'm not totally opposed to adding M4, I just think its a better use of
> your time to tell the 3 remaining OSX 10.4 users that they need to first
> compile their own M4.

And don't forget the 2 remaining Solaris users :-)

[Volker Braun]

On Wednesday, June 20, 2012 2:07:48 PM UTC+1, Jeroen Demeyer wrote:

And don't forget the 2 remaining Solaris users :-)

Mariah already compiled M4 on mark and mark2, so they are covered ;-) 

[kcrisman]

On Wednesday, June 20, 2012 6:55:42 AM UTC-4, Volker Braun wrote:

The minimal required version, GNU M4 1.4.5, was released in 2006. Are there still people using a 6-year old Mac to compile Sage? Does it have enough memory to build the 2012 developer guide? ;-)

Yes and yes, but at least mine build 5.0.1 fine.    Is the problem the C interface to PPL required by the optional package in #12666?  Probably one can just blacklist that old of a version of Xcode and not install the C interface.  It doesn't exactly look like this C interface is necessary for the vast majority of Sage operations, and one can probably assume that anyone on such an old system will not notice if #12666 is unable to be installed.

[Jeroen Demeyer]

On 2012-06-20 17:07, kcrisman wrote:
>
>
> On Wednesday, June 20, 2012 6:55:42 AM UTC-4, Volker Braun wrote:
>
> The minimal required version, GNU M4 1.4.5, was released in 2006.
> Are there still people using a 6-year old Mac to compile Sage? Does
> it have enough memory to build the 2012 developer guide? ;-)
>
>
>
> Yes and yes, but at least mine build 5.0.1 fine. Is the problem the C
> interface to PPL required by the optional package in #12666?

It's really about #12672 and #11391 (which are different problems with
the same solution).

Sure, we could change PPL but in terms of time-efficiency (which Volker
seems to find important), adding an M4 spkg is easier than figuring out
exactly when to install PPL with its C interface.

Seeing that we already include "patch" and "iconv" with Sage, why not
add "m4" also?

[Dima Pasechnik]

inclusion of patch and iconv into Sage could perhaps be reviewed... 

[Jeroen Demeyer]

Since we just got another report of #11391, I would like to propose
again to add GNU m4 as standard package. The only possible argument
against it would be that it makes the Sage source about 1MB larger...

[Jean-Pierre Flori]

I'd be in favour of including M4 as well.

Moreover, now it's already distributed in the optional autotools spkg (which is really useful for development).

One might argue that all systems nowadays should have a decent m4 already, as patch and iconv we ship as well.
But it does not seem to be the case that iconv is always decent (at least on some Solaris, not sure about Cygwin today), and must have been for patch (not sure today neither).
And are always these packages installed by default?

Ideally, from my point of view, I would prefer to have a completely modular Sage and just do "apt-get install sage" but I fear it won't happen soon.
The only use case of a quasi selfcontained distrib is that someone without root privileges but a decent gcc and perl installed can build Sage in a user directory and shipping m4 will help that a little more.

[Julien Puydt]

Le 20/12/2012 17:27, Jean-Pierre Flori a �crit :

> Ideally, from my point of view, I would prefer to have a completely
> modular Sage and just do "apt-get install sage" but I fear it won't
> happen soon.

We're already a few working on it and things are progressing slowly.

You're welcome to join in the effort.

Snark on #sagemath and #debian-science

PS:
There's a new, automatically updated page (mine was done by hand...
which explains why it's a little behind the times) about the status of
things in debian compared to sage:

http://people.debian.org/~thansen/debian-sage-status.html

(it's not perfect though ; for example eclib's status is broken: debian
is up to date)

[Jean-Pierre Flori]

On Thursday, December 20, 2012 5:52:33 PM UTC+1, Snark wrote:

Le 20/12/2012 17:27, Jean-Pierre Flori a �crit :

Not really anymore :)
See #13325.

[Jean-Pierre Flori]

On Thursday, December 20, 2012 5:52:33 PM UTC+1, Snark wrote:

Le 20/12/2012 17:27, Jean-Pierre Flori a �crit :

> Ideally, from my point of view, I would prefer to have a completely
> modular Sage and just do "apt-get install sage" but I fear it won't
> happen soon.

We're already a few working on it and things are progressing slowly.

Great!

You're welcome to join in the effort.
 

I'll have to learn how to package debian archives first... but I'm interested in that as well.

Snark on #sagemath and #debian-science

Anyway, I still think it might be a good idea to ship m4 in the big fat Sage self sufficient distribution.
Of course it should not be included in a fuutre sagemath debian package.

[Jean-Pierre Flori]

I've created #14381 to at least separate m4 from autotools stuff.

[leif]

Jean-Pierre Flori wrote:
> I've created #14381 to at least separate m4 from autotools stuff.

Separating it certainly makes sense; I'd still keep it optional though.

Of course you need some sufficiently working C compiler to bootstrap GCC
4.{6,7}, as GCC depends on GMP/MPIR, and the latter on M4... :-)

But nevertheless, 'sage -i m4' should work right after unpacking the
Sage source tarball, before anything else is built ('make').

IMHO there should be a "download only" option to sage-spkg, mainly to
install optional packages needed for building Sage... (Optionally:
Specify [alternate] target directory, let Sage use some
SAGE_ADDITIONAL_SPKGS_DIR[S].)


-leif

P.S.: I still think we should have some lean Sage source tarball, and
another with all standard foo stuff (iconv, patch, GCC etc.) included,
at least until we move to another package management / build /
distribution system.

--
() The ASCII Ribbon Campaign
/\ Help Cure HTML E-Mail

[Jean-Pierre Flori]

On Friday, March 29, 2013 12:49:02 PM UTC+1, leif wrote:

Jean-Pierre Flori wrote:
> I've created #14381 to at least separate m4 from autotools stuff.

Separating it certainly makes sense; I'd still keep it optional though.

Of course you need some sufficiently working C compiler to bootstrap GCC
4.{6,7}, as GCC depends on GMP/MPIR, and the latter on M4... :-)

But nevertheless, 'sage -i m4' should work right after unpacking the
Sage source tarball, before anything else is built ('make').

IMHO there should be a "download only" option to sage-spkg, mainly to
install optional packages needed for building Sage...  (Optionally:

Wasn't it discussed at some point?
I'll have a quick look.