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

Move local/bin/sage-check-64 to spkg/bin/sage-arch-env #12789

Closed
jdemeyer opened this issue Apr 2, 2012 · 20 comments
Closed

Move local/bin/sage-check-64 to spkg/bin/sage-arch-env #12789

jdemeyer opened this issue Apr 2, 2012 · 20 comments

Comments

@jdemeyer
Copy link

jdemeyer commented Apr 2, 2012

Since sage-env sources $SAGE_LOCAL/bin/sage-check-64, it makes sense to move the latter file to $SAGE_ROOT/spkg/bin. I also propose to rename the file to "sage-arch-env". I would like to support a SAGE32 flag (see #12726) and it makes sense to use the same file for this.

Further changes:

  1. use $SAGE_LOCAL/etc/sage-64.txt as indicator file for SAGE64 instead of $SAGE_LOCAL/lib/sage-64.txt (sage-64.txt looks more like a configuration file than a library).
  2. remove all "echo" statements from sage-check-64 (they were being redirected to /dev/null anyway).
  3. move the sourcing of this file up in sage-env, before the compiler flags are set. This would allow changing the default compiler flags, depending on SAGE64 or other future architecture flags.
  4. remove sourcing of sage-check-64 from local/bin/sage-build. The latter script is only called from spkg/bin/sage at which point SAGE64 is already set if needed.
  5. remove all uname checks: don't make a difference between OS X, Solaris and other systems (it doesn't mean SAGE64 is supported on all systems of course).
  6. if SAGE64 is set to "no", delete sage-64.txt.

Apply:

  1. attachment: 12789_scripts.patch to the SCRIPTS repository.
  2. attachment: 12789_root.patch to the ROOT repository.

Component: scripts

Keywords: sd40.5

Author: Jeroen Demeyer

Reviewer: Volker Braun

Merged: sage-5.1.beta4

Issue created by migration from https://trac.sagemath.org/ticket/12789

@jdemeyer jdemeyer added this to the sage-5.1 milestone Apr 2, 2012
@jdemeyer

This comment has been minimized.

@jdemeyer
Copy link
Author

jdemeyer commented Apr 2, 2012

Author: Jeroen Demeyer

@jdemeyer

This comment has been minimized.

@jdemeyer

This comment has been minimized.

@jdemeyer

This comment has been minimized.

@jdemeyer

This comment has been minimized.

@jhpalmieri
Copy link
Member

comment:7

I haven't looked at the patches here, but #10303 and #11077 also had some ideas for clean up for sage-check-64.

@jdemeyer
Copy link
Author

jdemeyer commented Apr 2, 2012

comment:8

Replying to @jhpalmieri:

I haven't looked at the patches here, but #10303 and #11077 also had some ideas for clean up for sage-check-64.

Too bad those tickets got abandoned, as they are bitrotten now. Anyway, I will look at those tickets and take the good ideas here.

@jdemeyer

This comment has been minimized.

@jdemeyer
Copy link
Author

jdemeyer commented Apr 2, 2012

comment:10

Added items 5 and 6.

One idea from #10303 that I disagree with is to source sage-check-64 (now sage-arch-env) only in sage-spkg and sage-build, i.e. when a package is being built. I think it can be useful even within Sage, for example to compile Cython files.

@nexttime
Copy link
Mannequin

nexttime mannequin commented Apr 2, 2012

comment:11

Replying to @jdemeyer:

Added items 5 and 6.

One idea from #10303 that I disagree with is to source sage-check-64 (now sage-arch-env) only in sage-spkg and sage-build, i.e. when a package is being built. I think it can be useful even within Sage, for example to compile Cython files.

Well, Cython should take CFLAGS etc. from distutils, i.e., Python.

Doesn't really make sense to change the settings (SAGE64 or whatever) afterwards or inbetween. Either you do (or have) a 64-bit build, or not. The original purpose of the sage-64.txt file is exactly to avoid mixing up 32-bit and 64-bit builds (although there are certainly better ways to achieve this).

@nexttime
Copy link
Mannequin

nexttime mannequin commented Apr 2, 2012

comment:12

Shouldn't there be at least a warning if SAGE64 is set to "no" but sage-64.txt already exists?

Since this is exactly what we want to avoid: Mixing up both.

@jdemeyer
Copy link
Author

jdemeyer commented Apr 3, 2012

comment:13

Replying to @nexttime:

Shouldn't there be at least a warning if SAGE64 is set to "no" but sage-64.txt already exists?

I believe in the philosophy of "user is always right". If the user intentionally set SAGE64=yes and then later SAGE64=no, we assume he knows what he's doing. I don't see the need for a warning. Besides, the warning would only be printed once (sage-64.txt is deleted if SAGE64=no), so it would be easy to miss.

@jdemeyer
Copy link
Author

jdemeyer commented Apr 3, 2012

comment:14

Replying to @nexttime:

Well, Cython should take CFLAGS etc. from distutils, i.e., Python.

Perhaps, but I think it's not impossible that some Sage library code or user code wants to look at SAGE64. However, I'm not going to insist on this. I just want this ticket to get reviewed and merged, unlike #10303.

@jdemeyer

This comment has been minimized.

@jdemeyer
Copy link
Author

Attachment: 12789_scripts.patch.gz

@vbraun
Copy link
Member

vbraun commented May 26, 2012

Changed keywords from none to sd40.5

@vbraun
Copy link
Member

vbraun commented May 26, 2012

comment:16

Attachment: 12789_root.patch.gz

Looks good!

@vbraun
Copy link
Member

vbraun commented May 26, 2012

Reviewer: Volker Braun

@jdemeyer
Copy link
Author

Merged: sage-5.1.beta4

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants