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

Gather and clean up compiler flags #30375

Closed
kliem opened this issue Aug 16, 2020 · 88 comments
Closed

Gather and clean up compiler flags #30375

kliem opened this issue Aug 16, 2020 · 88 comments

Comments

@kliem
Copy link
Contributor

kliem commented Aug 16, 2020

We gather and clean up compiler flags. Also we

  • add --enable-fat-binary to configure (as an alternative to setting SAGE_FAT_BINARY)
  • add --enable_debug={no|symbols|yes} as alternative to setting SAGE_DEBUG
  • compile with -Og -g if SAGE_DEBUG=yes
  • compile with -O2 if SAGE_DEBUG=no (some packages with O3 instead)
  • compile with -O2 -g otherwise (some packages with O3 instead)

During the build of Sage there are now flags that can be exported
in spkg_install.in with one line, instead of checking SAGE_DEBUG
etc. for each individual package, e.g. by

  • export CFLAGS=$CFLAGS (redundant, use flags as above)
  • export CFLAGS=$CFLAGS_O3 (O3 instead of O2, but only if not in debug mode)
  • export CFLAGS=$ORIGINAL_CFLAGS (use $CFLAGS as set before configure)

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

make CFLAGS=-O2 some-package

or

make SAGE_DEBUG="yes" some-package

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

@kliem kliem added this to the sage-9.2 milestone Aug 16, 2020
@kliem kliem modified the milestones: sage-9.2, sage-9.3 Aug 16, 2020
@slel

This comment has been minimized.

@mkoeppe
Copy link
Contributor

mkoeppe commented Oct 15, 2020

comment:3

One point that probably needs discussion is the following.

When an spkg is built, the current design of sage-spkg is to create a self-contained script spkg-install that sets all necessary environment variables (by sourcing sage-env etc.). (This makes it relatively easy to debug the installation process.)

Making package installs depend on exported environment variables in Makefile.in breaks this design.

It would probably be better to create a new script sage-build-env (to complement sage-build-env-config) to take care of these environment variable settings.

@kliem
Copy link
Contributor Author

kliem commented Oct 16, 2020

comment:4

Ok, I think I'm beginning to understand.

Create a new file build/bin/sage-build-env.in and move the stuff that I added to the makefile there?

Then make sure build/bin/sage-build-env is added to the correct places?

Why should I not add the things to build/bin/sage-build-env-config directly?

@mkoeppe
Copy link
Contributor

mkoeppe commented Oct 16, 2020

comment:5

Replying to @kliem:

Create a new file build/bin/sage-build-env.in and move the stuff that I added to the makefile there?

Then make sure build/bin/sage-build-env is added to the correct places?

Yes

Why should I not add the things to build/bin/sage-build-env-config directly?

Just a suggestion, to keep the analogy to src/bin/sage-env (which implements some logic) and src/bin/sage-env-config (which purely sets some variables). Not very important.

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Oct 17, 2020

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

b6cf7c1Merge branch 'u/gh-kliem/gather_and_clean_up_compile_flags' of git://trac.sagemath.org/sage into u/gh-kliem/gather_and_clean_up_compile_flags_new

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Oct 17, 2020

Changed commit from 2ff5630 to b6cf7c1

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Oct 18, 2020

Changed commit from b6cf7c1 to 5f4d0b1

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Oct 18, 2020

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

5f4d0b1bash syntax again

@kliem
Copy link
Contributor Author

kliem commented Oct 18, 2020

comment:8

I think I have mostly figured it out.

But it seems that this is no longer applied. If I configure with some CFLAGS, it seems that when making still the standard CFLAGS are applied. It is consistent with the CFLAGS in sage -sh at least.

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Oct 18, 2020

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

a913bbdcorrect detextion of empty values

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Oct 18, 2020

Changed commit from 5f4d0b1 to a913bbd

@kliem
Copy link
Contributor Author

kliem commented Oct 18, 2020

comment:10

Ok, seems to work now.

And in the sage -buildsh this thing is run correctly.

@mkoeppe
Copy link
Contributor

mkoeppe commented Oct 22, 2020

comment:11

Looking good; but I think sage-build-env would ideally not be a generated file but rather get its settings from sage-build-env-config.

@mkoeppe
Copy link
Contributor

mkoeppe commented Oct 22, 2020

comment:12

(If both are generated, there is really no point in splitting into these two files)

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Oct 26, 2020

Changed commit from a913bbd to 3b82fe9

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Oct 26, 2020

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

3b82fe9Merge branch 'u/gh-kliem/gather_and_clean_up_compile_flags' of git://trac.sagemath.org/sage into u/gh-kliem/gather_and_clean_up_compile_flags_new

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Oct 26, 2020

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

d979c22do not generate `sage-build-env`; respect environment settings at make time

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Oct 26, 2020

Changed commit from 3b82fe9 to d979c22

@mkoeppe
Copy link
Contributor

mkoeppe commented Oct 27, 2020

comment:15

Would it not be cleaner if instead of

+# The configured compilation flags.
+if [ "x$CFLAGS" == "x" ]; then
+    export CFLAGS="@ORIGINAL_CFLAGS@"
+fi

in build-env-config, you would unconditionally set a variable ORIGINAL_CFLAGS?

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Oct 27, 2020

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

e898e33more natural naming

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Oct 27, 2020

Changed commit from d979c22 to e898e33

@kliem
Copy link
Contributor Author

kliem commented Oct 27, 2020

comment:17

I don't understand anything at this point anymore.

$ export CFLAGS='-march=native'
$ export CXXFLAGS='-O1'
$ ./configure
$ sage --buildsh
echo $CFLAGS
-march=native
echo $CXXFLAGS
-O1

Okay, this is exactly what we want. But

export CFLAGS='-march=native'
./configure CXXFLAGS='-O1'
sage --buildsh
echo $CFLAGS
-march=native
echo $CXXFLAGS
-march=native

Why? build/bin/sage-build-env-config was configured exactly the same. However, if you echo $CXXFLAGS at the start of build/bin/sage-build-env/config, you see that CXXFLAGS was already set to -march=native. Were does this come from?

  • At the moment I overwrite CFLAGS etc. conditionally so that a user may run make CFLAGS='-Og' <some package>. ORIGINAL_CFLAGS should be the same as this value in this case, shouldn't it (and all other related values as well: CFLAGS_O3 etc). Any package may choose any such environment variable and append flags, but should never discard flags the user handed in.

    It is really confusing however, that the exported stuff at configure time is called ORIGINAL_CFLAGS, as @CFLAGS@ already tells us that this is from configure time. I changed that.


New commits:

e898e33more natural naming

@mkoeppe
Copy link
Contributor

mkoeppe commented Oct 27, 2020

comment:18

Note that also sage-env and sage-env-config are sourced.

@mkoeppe
Copy link
Contributor

mkoeppe commented Dec 3, 2020

comment:55

Replying to @kliem:

From https://www.gnu.org/software/autoconf/manual/autoconf-2.66/html_node/Fortran-Compiler.html

The AC_FC_FREEFORM tries to ensure that the Fortran compiler ($FC) allows free-format source code (as opposed to the older fixed-format style from Fortran 77). If necessary, it may add some additional flags to FCFLAGS.

So, AC_FC_FREEFORM has added -ffree-form to my flags, because it feels that this is needed. So I think, we should either respect that or not call AC_FC_FREEFORM.

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.

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Dec 3, 2020

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

87dae61keep FCFLAGS during gfortran configure

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Dec 3, 2020

Changed commit from 94326db to 87dae61

@kliem
Copy link
Contributor Author

kliem commented Dec 3, 2020

comment:57

Ok. I'm storing and restoring the FCFLAGS during gfortran configure now.
Defining a macro was the only way, I could enforce the order. But maybe there is a better way of doing this.

@mkoeppe
Copy link
Contributor

mkoeppe commented Dec 3, 2020

comment:58

That's fine, yes, AC_FC_FREEFORM is executed out of order.

These lines:

+    sage_saved_fcflags=$FCFLAGS
+    FCFLAGS=$sage_saved_fcflags

need quoting around the assigned value.

@mkoeppe
Copy link
Contributor

mkoeppe commented Dec 3, 2020

comment:59

Also these macro calls are better without the use of the second argument (look at the generated shell code)

+# Save compiler flags as configured by the user.
+AC_SUBST(CFLAGS, "$CFLAGS")
+AC_SUBST(CXXFLAGS, "$CXXFLAGS")
+AC_SUBST(FCFLAGS, "$FCFLAGS")
+AC_SUBST(F77FLAGS, "$F77FLAGS")

@kliem
Copy link
Contributor Author

kliem commented Dec 4, 2020

comment:60

Replying to @mkoeppe:

Also these macro calls are better without the use of the second argument (look at the generated shell code)

+# Save compiler flags as configured by the user.
+AC_SUBST(CFLAGS, "$CFLAGS")
+AC_SUBST(CXXFLAGS, "$CXXFLAGS")
+AC_SUBST(FCFLAGS, "$FCFLAGS")
+AC_SUBST(F77FLAGS, "$F77FLAGS")

Your proposed change does not work. AC_PROG_CC() changes the value of CFLAGS if not set. AC_SUBST(CFLAGS, "$CFLAGS") will implicitly set CFLAGS (even though possibly to the empty value), but prevents AC_PROG_CC from messing with it.

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Dec 4, 2020

Changed commit from 87dae61 to 7577dd4

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Dec 4, 2020

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

7577dd4added quotes

@kliem
Copy link
Contributor Author

kliem commented Dec 4, 2020

comment:62

Replying to @kliem:

Replying to @mkoeppe:

Also these macro calls are better without the use of the second argument (look at the generated shell code)

+# Save compiler flags as configured by the user.
+AC_SUBST(CFLAGS, "$CFLAGS")
+AC_SUBST(CXXFLAGS, "$CXXFLAGS")
+AC_SUBST(FCFLAGS, "$FCFLAGS")
+AC_SUBST(F77FLAGS, "$F77FLAGS")

Your proposed change does not work. AC_PROG_CC() changes the value of CFLAGS if not set. AC_SUBST(CFLAGS, "$CFLAGS") will implicitly set CFLAGS (even though possibly to the empty value), but prevents AC_PROG_CC from messing with it.

I could deal with it the same way, I did with the FCFLAGS and save all of those flags beforehand. Maybe that is cleaner.

@kliem
Copy link
Contributor Author

kliem commented Dec 6, 2020

comment:63

Maybe we can take care of this.

@kliem
Copy link
Contributor Author

kliem commented Dec 6, 2020

Changed keywords from compile flags to compile flags, sd111

@kliem
Copy link
Contributor Author

kliem commented Dec 9, 2020

Work Issues: make variables SAGE_DEBUG and SAGE_FAT_BINARY precious

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Dec 10, 2020

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

3bb3099prepare preciouos variables

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Dec 10, 2020

Changed commit from 7577dd4 to 3bb3099

@kliem
Copy link
Contributor Author

kliem commented Dec 10, 2020

comment:66

Ok, at least it is prepared for precious variables.

#29507 would have to take care of using this.

@kliem
Copy link
Contributor Author

kliem commented Dec 10, 2020

Changed work issues from make variables SAGE_DEBUG and SAGE_FAT_BINARY precious to none

@kliem
Copy link
Contributor Author

kliem commented Dec 10, 2020

comment:67

Actually, it kind of works.

During make, reconfiguration will be done using ./config.status and this one does not alter the variables.

@mkoeppe
Copy link
Contributor

mkoeppe commented Dec 11, 2020

comment:68

Looking great, let's get this in.

@kliem
Copy link
Contributor Author

kliem commented Dec 11, 2020

comment:69

Thanks again.

@vbraun
Copy link
Member

vbraun commented Dec 13, 2020

Changed branch from u/gh-kliem/gather_and_clean_up_compile_flags to 3bb3099

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

4 participants