-
-
Notifications
You must be signed in to change notification settings - Fork 481
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
Gather and clean up compiler flags #30375
Comments
This comment has been minimized.
This comment has been minimized.
comment:3
One point that probably needs discussion is the following. When an spkg is built, the current design of Making package installs depend on exported environment variables in It would probably be better to create a new script |
comment:4
Ok, I think I'm beginning to understand. Create a new file Then make sure Why should I not add the things to |
comment:5
Replying to @kliem:
Yes
Just a suggestion, to keep the analogy to |
Branch pushed to git repo; I updated commit sha1. New commits:
|
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:8
I think I have mostly figured it out. But it seems that this is no longer applied. If I configure with some |
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:10
Ok, seems to work now. And in the |
comment:11
Looking good; but I think |
comment:12
(If both are generated, there is really no point in splitting into these two files) |
Branch pushed to git repo; I updated commit sha1. New commits:
|
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:15
Would it not be cleaner if instead of
in |
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:17
I don't understand anything at this point anymore.
Okay, this is exactly what we want. But
Why?
New commits:
|
comment:18
Note that also |
comment:55
Replying to @kliem:
We run this to find out whether the configured Fortran compiler has a free form mode. We do this for our decision whether we have to install gfortran or not. But it must be up to the individual packages how they invoke the Fortran compiler. |
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:57
Ok. I'm storing and restoring the |
comment:58
That's fine, yes, These lines:
need quoting around the assigned value. |
comment:59
Also these macro calls are better without the use of the second argument (look at the generated shell code)
|
comment:60
Replying to @mkoeppe:
Your proposed change does not work. |
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:62
Replying to @kliem:
I could deal with it the same way, I did with the |
comment:63
Maybe we can take care of this. |
Changed keywords from compile flags to compile flags, sd111 |
Work Issues: make variables SAGE_DEBUG and SAGE_FAT_BINARY precious |
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:66
Ok, at least it is prepared for precious variables. #29507 would have to take care of using this. |
Changed work issues from make variables SAGE_DEBUG and SAGE_FAT_BINARY precious to none |
comment:67
Actually, it kind of works. During make, reconfiguration will be done using |
comment:68
Looking great, let's get this in. |
comment:69
Thanks again. |
Changed branch from u/gh-kliem/gather_and_clean_up_compile_flags to |
We gather and clean up compiler flags. Also we
--enable-fat-binary
toconfigure
(as an alternative to settingSAGE_FAT_BINARY
)--enable_debug={no|symbols|yes}
as alternative to settingSAGE_DEBUG
-Og -g
ifSAGE_DEBUG=yes
-O2
ifSAGE_DEBUG=no
(some packages withO3
instead)-O2 -g
otherwise (some packages withO3
instead)During the build of Sage there are now flags that can be exported
in
spkg_install.in
with one line, instead of checkingSAGE_DEBUG
etc. for each individual package, e.g. by
export CFLAGS=$CFLAGS
(redundant, use flags as above)export CFLAGS=$CFLAGS_O3
(O3
instead ofO2
, but only if not in debug mode)export CFLAGS=$ORIGINAL_CFLAGS
(use$CFLAGS
as set beforeconfigure
)Likewise we do with
CXXFLAGS
,FCFLAGS
,F77FLAGS
.We try to respect the user's choice and do not overwrite the flags if already
set by the user, but only add compile flags if necessary for packages to work.
Inidividual packages can still be compiled with specified flags or in debug mode using
or
This ticket prepares #27122, which adds
-march=native
to the defaults.CC: @slel @dimpase
Component: build
Keywords: compile flags, sd111
Author: Jonathan Kliem
Branch/Commit:
3bb3099
Reviewer: Matthias Koeppe
Issue created by migration from https://trac.sagemath.org/ticket/30375
The text was updated successfully, but these errors were encountered: