Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tighten up rules on loading workspaces #1089

Closed
ChrisJefferson opened this issue Jan 18, 2017 · 2 comments
Closed

Tighten up rules on loading workspaces #1089

ChrisJefferson opened this issue Jan 18, 2017 · 2 comments
Labels
kind: enhancement Label for issues suggesting enhancements; and for pull requests implementing enhancements

Comments

@ChrisJefferson
Copy link
Contributor

ChrisJefferson commented Jan 18, 2017

At the moment GAP checks the kernel version when loading workspaces (so for example 4.4.11 won't load a 4.4.10 workspace). I would like to suggest the following tightening of the rules:

  • Reject if HAVE_LIBREADLINE is different
  • Reject if BUILD_VERSION is different (that is, the git version the kernel was build from)

Only the last one I imagine might be controversial, but I think we should do it, as a few times I have found it can produce hard-to-debug errors. We could instead in this last case just produce a warning if people really want to be able to try it.

EDIT: I wondered about rejecting if GMP_VERSION is different, but I don't think that should effect workspaces, and would break workspaces when the OS updates the GMP version.

The coding for this is easy, but I wanted to get thoughts before starting.

Would fix #1079

@stevelinton
Copy link
Contributor

The GMP version would only matter if gmp changed it's mpn binary data format, which seems pretty unlikely.

@fingolfin fingolfin added the kind: enhancement Label for issues suggesting enhancements; and for pull requests implementing enhancements label May 9, 2017
@fingolfin
Copy link
Member

This was fixed by PR #2720
@ChrisJefferson the "fixes" keyword must appear for before each issue number in order for the issue to be auto-closed when the PR gets merged.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind: enhancement Label for issues suggesting enhancements; and for pull requests implementing enhancements
Projects
None yet
Development

No branches or pull requests

3 participants