| View previous topic :: View next topic |
| Author |
Message |
lars_the_bear
Guru
Joined: 05 Jun 2024
Posts: 522
|
 Posted: Tue Jun 18, 2024 2:15 pm Post subject: How does Portage run make? |
 |
|
Hi folks
I'm writing ebuild files for utilities that I maintain myself, that I would normally just build from source manually on a new installation. My utilities are all C, and have a simple Makefile for building. I thought it would be nice to write my own overlay that I can use with multiple machines.
To my surprise, it wasn't difficult to implement ebuild files for these utilities. But I'm confused about something.
In my make.conf I have
CFLAGS=-O2
and in my application's Makefiles I invariably have
CFLAGS := -Wall -O3...
I notice that the invocation of 'make' by emerge does not override the CFLAGS settings in the Makefile. That is, gcc gets run with '-Wall -O3' and not '-O2'.
It isn't a problem, because the build works fine. But I wonder -- what effect does setting CFLAGS in make.conf actually have? How does emerge pass the CFLAGS settings from make.conf into the build, anyway? Should I do something special in my application's Makefiles, to make them more friendly to Gentoo?
BR, Lars. |
|
| Back to top |
|
 |
grknight
Retired Dev
Joined: 20 Feb 2015
Posts: 1922
|
| Posted: Tue Jun 18, 2024 2:27 pm Post subject: |
|
|
Perhaps change your Makefile to either:
CFLAGS:=-Wall -O3 $(CFLAGS)
or
CFLAGS?=-Wall -O3
depending on the situation. The former appends user flags at the end while keeping your defaults or the latter only sets defaults if the user/environment does not pass anything.
Remember with -O, and most gcc options, the last value wins so it is fine to repeat. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22685
|
| Posted: Tue Jun 18, 2024 2:33 pm Post subject: |
|
|
| Setting CFLAGS in make.conf sets the process environment variable CFLAGS, which GNU make would use if the Makefile were not overriding it. Generally, Gentoo packages consider it a bug that the upstream Makefile ignores the user's CFLAGS, as happens here. Solutions vary. Sometimes the Makefile is patched to respect CFLAGS. Sometimes the ebuild overrides the flags with a command line assignment. |
|
| Back to top |
|
|
lars_the_bear
Guru
Joined: 05 Jun 2024
Posts: 522
|
| Posted: Tue Jun 18, 2024 7:35 pm Post subject: |
|
|
| Hu wrote: | | Generally, Gentoo packages consider it a bug that the upstream Makefile ignores the user's CFLAGS, as happens here. |
I can see why one might hold such a view, but I'm not sure it would be widely accepted. If I say in my Makefile
CFLAGS := -Wall...
then the user can override the CFLAGS setting using
$ make CFLAGS=...
I would assume that if the user is supplying CFLAGS, then he means to supply all the flags, not just add to mine. In any event, I have:
EXTRA_CFLAGS ?=
CFLAGS := -Wall -Wno-unused-result -O3 $(EXTRA_CFLAGS)
So the user can supply additional flags if required.
Writing
CFLAGS := .... $(CFLAGS)
doesn't seem very idiomatic to me. But maybe things have moved on, since I learned to write Makefiles thirty years ago 
Leaving aside philosophical matters, it seems that what I want in my ebuild script is a way to run make like this:
EXTRA_CFLAGS=$CFLAGS make ...
Or, I guess, I could just sed the Makefile and change the way CFLAGS is used. I will work out how to do this, if I can.
Is there anything else I have to watch out for?
BR, Lars.
PS. I always use "-O3" and test my code that way. I imagine that anybody else who is using my code, is using it that way. On the one hand, I can see why I should respect a user's choice to use "-O2" (or whatever) if he wants. On the other hand, that's not how I test my code. Is there some particular Gentoo way to handle that situation? |
|
| Back to top |
|
|
grknight
Retired Dev
Joined: 20 Feb 2015
Posts: 1922
|
| Posted: Tue Jun 18, 2024 7:43 pm Post subject: |
|
|
| lars_the_bear wrote: | Leaving aside philosophical matters, it seems that what I want in my ebuild script is a way to run make like this:
EXTRA_CFLAGS=$CFLAGS make ...
|
In an ebuild, use emake and not make. emake is a helper script included with Portage which includes items such as not continuing on a failed build, automatic MAKEOPTS inclusion, etc. |
|
| Back to top |
|
|
eschwartz
Developer
Joined: 29 Oct 2023
Posts: 228
|
| Posted: Tue Jun 18, 2024 8:16 pm Post subject: |
|
|
| lars_the_bear wrote: | | Hu wrote: | | Generally, Gentoo packages consider it a bug that the upstream Makefile ignores the user's CFLAGS, as happens here. |
I can see why one might hold such a view, but I'm not sure it would be widely accepted. If I say in my Makefile
CFLAGS := -Wall...
then the user can override the CFLAGS setting using
$ make CFLAGS=...
I would assume that if the user is supplying CFLAGS, then he means to supply all the flags, not just add to mine. In any event, I have:
EXTRA_CFLAGS ?=
CFLAGS := -Wall -Wno-unused-result -O3 $(EXTRA_CFLAGS)
So the user can supply additional flags if required.
|
It's widely accepted and enforced by real projects that use real build systems (autotools, meson, cmake...)
You are engaging in self-defeating behavior. Why does the concept of a variable called "CFLAGS" exist, if you then use CFLAGS as an internal implementation detail and expect make.conf to define EXTRA_CFLAGS instead?
Why not just do the thing that properly written Makefiles (insomuch as a raw Makefile can ever be proper without the ability to make decisions) have done for decades?
| Code: |
CFLAGS ?=
MYCFLAGS := -Wall -Wno-unused-result -O3 $(CFLAGS)
|
Actually, it should be:
| Code: |
CFLAGS ?= -O3
MYCFLAGS := -Wall -Wno-unused-result $(CFLAGS)
|
| lars_the_bear wrote: |
Writing
CFLAGS := .... $(CFLAGS)
doesn't seem very idiomatic to me. But maybe things have moved on, since I learned to write Makefiles thirty years ago
|
No, it was wrong 30 years ago too. Autoconf was released in 1991. It handles this for you even without involving automake or libtool, simply processing decisions such as --prefix or variables such as ${CFLAGS} in a standards-conformant manner and doing text substitution of
| Code: |
CFLAGS = -Wall -Wno-unused-result -O3 @CFLAGS@
|
via sed.
| lars_the_bear wrote: |
PS. I always use "-O3" and test my code that way. I imagine that anybody else who is using my code, is using it that way. On the one hand, I can see why I should respect a user's choice to use "-O2" (or whatever) if he wants. On the other hand, that's not how I test my code. Is there some particular Gentoo way to handle that situation? |
I don't particularly care if your Makefile ignores my default of -O2 since I'm "okay" with -O3 too.
I do, however, care that it ignores:
-march=native -fstack-protector-all -fdiagnostics-color=always -frecord-gcc-switches -flto=4 -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing -Wformat -Werror=format-security -Werror=implicit-function-declaration -Werror=implicit-int -Werror=int-conversion -Werror=incompatible-pointer-types
LTO is very nice, but not all compilers support it and you may need different values depending on compiler.
Many of these flags are diagnostics to detect erroneous code that would break with -O3 but only if you use it on CPUs that aren't an x86 or amd64.
-march=native is a good choice for local compilations but a terrible one for binhosts.
There are many such decisions. This is why it's objectively a bug if a Makefile doesn't support the portage defined "$CFLAGS and $LDFLAGS are defined in the environment, and Makefiles should respect them, and if the Makefiles don't respect them then the ebuild should patch the Makefile to start respecting them".
The Gentoo way to handle that situation is:
| Code: |
PATCHES=(
"${FILESDIR}"/${P}-respect-cflags.patch
)
|
(FILESDIR is the files/ directory next to the ebuild itself) where the patch file causes the Makefile to read CFLAGS from the environment and append it to the project-internal CFLAGS.
It may also delete lines such as "CC = gcc" since POSIX Make doesn't support ?= and many Makefiles therefore insist to "set it to a sane default" except it isn't actually that sane since it breaks in cross builds, clang systems, and more.
P.S. None of this is specific to Gentoo. Gentoo has the same policy that packages should respect $CFLAGS, as every other major distro has. |
|
| Back to top |
|
|
lars_the_bear
Guru
Joined: 05 Jun 2024
Posts: 522
|
| Posted: Tue Jun 18, 2024 9:13 pm Post subject: |
|
|
| eschwartz wrote: |
You are engaging in self-defeating behavior. Why does the concept of a variable called "CFLAGS" exist, if you then use CFLAGS as an internal implementation detail and expect make.conf to define EXTRA_CFLAGS instead?
|
Because I've done it that way for a long, long time. My way has always worked for me, and that everybody else does it differently -- if, indeed, they do -- won't change my approach.
I imagine it will be easier for me to hack an ebuild file to work with my Makefiles than it will be to change the habits of a lifetime. If that turns out not to be the case, I'll just run 'git clone xxx; make' at the prompt as I always have until now.
BR, Lars. |
|
| Back to top |
|
|
lars_the_bear
Guru
Joined: 05 Jun 2024
Posts: 522
|
| Posted: Wed Jun 19, 2024 2:49 pm Post subject: |
|
|
Turns out it's as simple as adding:
src_compile()
{
EXTRA_CFLAGS=$CFLAGS emake
}
That's got to be easier than rewriting 30 years's worth of code
BR, Lars. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Portage & Programming
