Opened 8 years ago

Closed 8 years ago

Last modified 6 years ago

#16178 closed enhancement (fixed)

Build maxima fasl without asdf

Reported by: gagern Owned by:
Priority: major Milestone: sage-6.2
Component: packages: standard Keywords: maxima ecl
Cc: Merged in:
Authors: Martin von Gagern Reviewers: François Bissey
Report Upstream: N/A Work issues:
Branch: 4511b5e (Commits, GitHub, GitLab) Commit:
Dependencies: Stopgaps:

Status badges

Description

Currently, the maxima install process uses asdf to create a fasl file. This has caused problems in several situations already, most notably in sage-on-gentoo. There I came up with a different approach, which doesn't use asdf but instead patches the maxima build instructions to emit the fasl along with the program. Essentially I duplicate the c::build-program invocation and turn that duplicate into c::build-fasl. I guess doing so might be beneficial to sage as well. I'll create this ticket here then start working on a branch which includes my approach.

References:

Change History (19)

comment:1 Changed 8 years ago by gagern

  • Branch set to u/gagern/ticket/16178
  • Created changed from 04/17/14 08:16:35 to 04/17/14 08:16:35
  • Modified changed from 04/17/14 08:16:35 to 04/17/14 08:16:35

comment:2 Changed 8 years ago by fbissey

  • Commit set to 880002dc3e5348bfa37ad722f3c099c1898b6128

Glad to see you taking the lead on that one. I was planning to do something about it post 6.2.


New commits:

880002dBuild maxima fasl without asdf.

comment:3 Changed 8 years ago by gagern

Note that this modification here should also allow upgrades to ECL, which in turn might benefit some other issues related to ECL. comment:46:ticket:14636 mentions the support for ECL 13.5.1 currently available for sage-on-gentoo. comment:47:ticket:14636 asks for a discussion related to upgrading the ECL pkg. As far as I can tell, there is no such ticket (yet) in sage trac.

I also notified ticket:11786 since it might be that this change fixes that issue as well.

comment:4 Changed 8 years ago by gagern

  • Status changed from new to needs_review

comment:5 Changed 8 years ago by fbissey

  • Status changed from needs_review to positive_review

In principle, I will put this as positive. It is not like we haven't been using the stuff for several months, and I did use it on OS X too.

comment:6 Changed 8 years ago by gagern

I wonder whether I should bump the patch level of the package version. If so, should I update SPKG.txt as well? If so, should I add a section about `maxima-5.29.1.p4` as well? With what content?

comment:7 follow-up: Changed 8 years ago by fbissey

  • Status changed from positive_review to needs_work

I knew I was forgetting something. We need to bump the patch level if we want this to be upgraded from the old way. As for SPKG.txt the new way is to slim them down because most of the interesting stuff is in the commit message, also a few lines about this wouldn't go amiss. Look at eclib and flint for current example.

comment:8 in reply to: ↑ 7 Changed 8 years ago by gagern

Replying to fbissey:

We need to bump the patch level if we want this to be upgraded from the old way.

That's the easy part.

As for SPKG.txt the new way is to slim them down because most of the interesting stuff is in the commit message[…]. Look at eclib and flint for current example.

Looking at them, and at the Developer's Guide, it seems as if the best way would be removing the Changelog.

I'm less sure about the information about “How to make a new version of the Maxima spkg”. I haven't tried it, don't know whether it's correct any more. If it is, should it be moved to the “Special Update/Build Instructions” section instead?

The part about spkg-dist seems to refer to what spkg-src does now. Perhaps that should go into a comment inside that script instead? Although this one sentence in the “Special Update/Build Instructions” already sums it up: “It removes a large amount of unused documentation and disables the associated Makefiles, reducing the size of the SPKG greatly.”

also a few lines about this wouldn't go amiss.

I'm unsure about what exactly you are referring to here. A few lines about the current SPKG.txt conventions, like those in the dev guide? Or a few lines about my modifications, despite the fact that this is against the trend of slimming the files down?

comment:9 Changed 8 years ago by fbissey

spkg-src and spkg-dist are for non trivial sources that requires special steps to produce beyond simple patching (pulling a particular revision and stuff like that). Here removing the documentation to save space. But we haven't really changed the sources to be distributed with sage so no concern.

I think in SPKG.txt you can create a section describing the patches and what they do. pari has a README.txt in the patches sub-folder but it also has a quantity of patches. Other than that, yes you can cull the changelog.

comment:10 Changed 8 years ago by git

  • Commit changed from 880002dc3e5348bfa37ad722f3c099c1898b6128 to 4511b5e13ef8492cf56b3485bea560bbcca3e763

Branch pushed to git repo; I updated commit sha1. New commits:

c7b6b72Bump maxima patch level.
4511b5eRemoved maxima change log.

comment:11 Changed 8 years ago by fbissey

  • Status changed from needs_work to positive_review

Yes, that looks OK now. Let's get on with it.

comment:12 Changed 8 years ago by vbraun

  • Reviewers set to François Bissey

reviewer name

comment:13 Changed 8 years ago by vbraun

  • Branch changed from u/gagern/ticket/16178 to 4511b5e13ef8492cf56b3485bea560bbcca3e763
  • Resolution set to fixed
  • Status changed from positive_review to closed

comment:14 follow-ups: Changed 8 years ago by dimpase

  • Commit 4511b5e13ef8492cf56b3485bea560bbcca3e763 deleted

asdf is the normal way to build Lisp packages, IMHO. Removing it is akin to removing makefiles and replacing them with hand-written scripts. Is it the way to go? asdf is actively developed and maintained. Perhaps one should ask for help instead?

I only saw this ticket on sage-release, that's why a late reaction.

comment:15 Changed 8 years ago by fbissey

Don't worry. The wording may be a bit misleading. We don't ditch asdf but instead of doing a separate invocation at the end to build the maxima library we patch the build system to build it in parallel. So asdf is not gone ;)

comment:16 in reply to: ↑ 14 Changed 8 years ago by gagern

Replying to dimpase:

asdf is the normal way to build Lisp packages, IMHO. Removing it is akin to removing makefiles and replacing them with hand-written scripts. Is it the way to go? asdf is actively developed and maintained. Perhaps one should ask for help instead?

To clarify in my own words: I'm not removing asdf, but I'm removing the use of a separate ASDF invocation to build the maxima library. If you look at the diff for 880002d, you will see that up to now, there would be several lines of ecl script in the spkg-install script, which do the asdf calling. As far as I know, noone has been able to make that work with more recent versions of ECL so far. Last I tried, I encountered two problems. The minor one was that apparently a lot of files got compiled twice, which is unneccessary work at the least. The major problem however is the fact that apparently maxima got initialized twice, which caused a stack overflow due to recursive copying of a cyclic data structure.

The reason for this, as I see it, is that maxima is neither designed to be used as a library, nor to be built with asdf. They directly speak to the ecl compiler functions, and call c::build-program. And the logical counterpart to c::build-program appears to be c::build-fasl. So all I'm doing is building a FASL in what seems closest to what Maxima already does.

I don't know enough lisp to decide how standard asdf is. But if asdf really were the (only) way to go, then I'd suggest you file a Maxima bug and ask them to switch their whole compilation process to asdf. Unless you are comfortable doing that, I don't see your argument applying to sage alone. To go with your metaphor: you have an application which is designed to build using a single hand-written build script, and now have to decide whether it is easier to patch that build script or to add an extra makefile to build some additional targets. Both approaches have drawbacks, neither is really clean, but if one is known to fail with newer releases of some component, I'd go with the one that still works.

comment:17 in reply to: ↑ 14 Changed 8 years ago by gagern

comment:14 deleted the Commit field of this ticket. What is the effect of that? Will it somehow prevent this feature from being included in the next release? If so, I believe that the current status of this ticket as closed fixed is no longer appropriate either. If, on the other hand, deleting the Commit field has not technical consequence, then I don't see the point. What's the intention there? Or was this something done automatically by some Trac plugin?

comment:18 Changed 8 years ago by vbraun

If you edit a comment after a push then trac will helpfully suggest to remove the "Commit:" field. Right now you need to click on the "revert" link in the preview before sending off the comment. Its a bug in our workflow but does not prevent the ticket from being merged (at least until it is fixed).

comment:19 Changed 6 years ago by infinity0

I've asked Maxima upstream to accept the FASL patch: https://sourceforge.net/p/maxima/patches/80/

I don't know the surrounding Lisp ecosystem very well, so please help me with making points etc in case they have reservations about it.

Note: See TracTickets for help on using tickets.