I need to add -Werror to the already existing (Exported?) CFLAGS for a build. Right now I am just trying to extract the data CFLAGS holds. I am super new to Make and Makefiles but have to add some pre-existing build files.
Say I have a target in a makefile like this
.PHONY: add_errors
add_errors:
#flags=$(CFLAGS);\
echo $$flags;\
But the issue is, CFLAGS is a really large string that has many options set.
When the makefile is executed I get the following error
/bin/sh: 1: -marm: not found
make[2]: *** [add_errors] Error 127
Which looks like something is taking the first space as the string and then discarding the rest of it.
Inside CFLAGS, a snippet of the text is
-march=armv5te -marm -mthumb-interwork -mtune=arm926ej-s --sysroot=/opt/dspg/v2.11-rc2/sysroots/cortexa9-neon-dspg-linux-gnueabi -Wno-psabi -ggdb -I/opt/dspg/v2.11-rc2/sysroots/cortexa9-neon-dspg-linux-gnueabi/usr/include/libxml2
What can I do?
You should ask a question which actually has some relation to what you really want to do, including relevant parts of the code. This example you gave is not useful for anything so the answer we give probably won't actually help you, but:
The first advice I have for you is NEVER use the # prefix on your recipes. Or at the very least never use them until AFTER your makefile is already working 100% correctly. Suppressing make's output like that is like trying to debug while blindfolded.
The problem is not related to make at all, really: it's just shell quoting rules.
If you remove the # and look at what make prints you'll see it's running this command:
flags=-march=armv5te -marm -mthumb-interwork -mtune=arm926ej-s ...; echo $flags;
If you cut and paste that to your shell, you'll get exactly the same error.
That's because the shell command foo=bar biz baz means, set the environment variable foo to the value bar then run the command biz with the argument baz.
You need to add quoting so that the shell puts all the arguments into the flags variable:
.PHONY: add_errors
add_errors:
#flags='$(CFLAGS)';\
echo $$flags;\
will cause make to run this:
flags='-march=armv5te -marm -mthumb-interwork -mtune=arm926ej-s ...'; echo $flags;
Related
Typical makefiles often use the built-in variables CFLAGS, CXXFLAGS, CPPFLAGS and so on1 to set the flags passed to the C, C++ or other compilers/tools. In principle, this sometimes even lets you avoid writing a compilation recipe entirely since the various built-in rules use these flags.
In general, a makefile might add things to the FLAGS variables that are required for the code to compile, such as include directories, arguments indicating which language standard to use and so on. The variables might also include "optional" or "default" arguments, such as optimization level, warning level and other settings that might validly be altered or removed.
Since CFLAGS and fields are "well known" variables, they are also apparently a configuration point for end users. For example, if a project compiles without debug information by default, it is expected that CFLAGS=-g on the make command line causes -g to be added to the $(CC) compiler command line and hence cause debug info to be produced. Similarly for other options the end user might want to control, such as the optimization level, the -march setting on gcc, and so on.
However, these two uses seem incompatible to me. If the user overrides $(CFLAGS) they will obliterate any internal "required" flags as described above, and the project either may not compile or may compile incorrectly.
Is there a best practice for handling this? The same problem doesn't really arise for "single value" variables like $(CC) since they generally have exactly one value: in this example, the C compiler to use. If the user overrides it, you use their value. Things like $(CFLAGS) are in principle a list of values, some of which are internal and shouldn't be overridden, an others which a user may want to override.
Intuitively, a solution seems to be to leave $(CFLAGS) and friends empty and unused in your makefile, preferring say CFLAGS_INTERNAL for in-makefile arguments, and then put both on the command line. I'm curious, however, if there is a best practice around this or if I'm missing something obvious.
1 For the rest of this question I will often simply refer to $(CFLAGS) with the understanding that this is simply a convenient representative of the whole family of well known compiler flag variables such as $(CPPFLAGS), $(CXXFLAGS) and so on.
I am faced with the same problem. For the time being my solution is to provide "non-standard" flags such as OPTIMS, WARNINGS, MODENV which will be appended to the "standard" CXXFLAGS internally.
If the user defines CXXFLAGS from the command-line it is assumed that he wants to override it, and if that's what he wants, that's what he should get: an override. Ironically this means I'm not using override CXXFLAGS += ... in the Makefile.
I don't want advanced users to pull their hairs out because I insist on appending/prepending my stuff to their flags, so in my opinion the final situation is like this:
GOOD: require advanced users to pass intricate custom flags
BAD: require advanced users to patch the Makefile
Just stumbled upon the same question while building an RPM with debuginfo package.
The requirement for debuginfo generation is to pass -g in CFLAGS while preserving whatever CFLAGS the software has in its Makefile.
So if you want to add some extra bits to CFLAGS, without overwriting the ones present in Makefile, you can simply use CFLAGS as an environment variable. But only as long as the Makefile in question uses CFLAGS += ... notation.
Example, suppose that you have software with Makefile having:
CFLAGS += $(ARCH) -O3 -std=gnu11 -Wall ...
To have it build with all those flags and -g, you will do:
CFLAGS='-g' make
Note that passing it as an argument to make won't work, as in: make CFLAGS='-g' is wrong, because it will overwrite internal CFLAGS.
More on the solution to pass -g for building debuginfo packages properly
Here's reference on make: appending to variables.
The approach I prefer is to provide sensible default values to these common variables, but let users provide their own - overriding the default values.
include $(wildcard makefile.in Makefile.in)
BUILD ?= build
CFLAGS ?= -O2 -fPIC -pedantic -Wall -Wextra -Wconversion
This can be done by either environment variables, command line parameters like make CFLAGS=-g or persistently in a makefile.in.
I am aware that this doesn't exactly pick up the issue you described in the questions, but I found use cases in which users want to compile a project with non-default flags should be able to
Define these variables to their needs
Check their defaults, preferably at the top of the makefile
Maybe adjust the definitions in accordance to the defaults
If someone wants to build with some special flags and is incapable of these steps, there will be some more serious problems anyhow.
This approach will not scale well when the build becomes more involved and the defaults are set across a larger makefile and dependent on other conditions.
The override directive may be what you are looking for:
$ cat Makefile
override CFLAGS += -foobar
all:
$(info CFLAGS = $(CFLAGS))
$ make
CFLAGS = -foobar
make: 'all' is up to date.
$ make CFLAGS=-g
CFLAGS = -g -foobar
make: 'all' is up to date.
Note that you can also use:
$ make CFLAGS+=-g
on the command line but it behaves just like:
$ make CFLAGS=-g
Ive got some large make files for a third party project that are not building due to linker issues.
From looking at the make files, I think it should be executing something like:
LIBS = -lm
CC = gcc
bin = bin
myapp: $(bin)/main.o $(bin)/other.o $(bin)/etc.o
$(CC) $(bin)/main.o $(bin)/other.o $(bin)/etc.o $(LIBS) -o myapp
gcc bin/main.o bin/other.o bin/etc.o -lm -o myapp
Instead from the error it seems to be failing on something like: It also didn't put any of the .o files in the expected bin/ location, but just left them in the source directory...
cc main.o -o myapp
But I cant locate anywhere that might come from. Is there some way to get some kind of stacktrace through the make files?
I am aware of -n and -d, but neither seems to tell me what target line and file yeilded that command, or which series of targets led there and the values of any $() expansions (The one im expecting is the only myapp: I can find in any of the makefiles...)
Check out the --debug option. From my manpage:
--debug[=FLAGS]
Print debugging information in addition to normal processing. If the
FLAGS are omitted, then the behavior is the same as if -d was specified.
FLAGS may be a for all debugging output (same as using -d), b for basic
debugging, v for more verbose basic debugging, i for showing implicit
rules, j for details on invocation of commands, and m for debugging
while remaking makefiles.
remake is a very good choice but in a pinch something like the following (saved as debug.mk) can be a good help too. It won't tell you as much as remake but it might tell you enough to start with.
# Use as: MAKEFILES=debug.mk make
OLD_SHELL := $(SHELL)
ifneq (undefined,$(origin X))
override X = -x
endif
SHELL = $(if $#,$(warning Running $#$(if $<, (from: $<))$(if $?, (newer: $?))))$(OLD_SHELL) $(X)
You can print out the other automatic variables there too if you wanted to see a bit more about what was going on.
I'm new to using makefiles and trying to produce a basic makefile as part of an exercise for university. I have two source code files, chello.c and writeexit.s, which have to be compiled/assembled and then linked to produce chello.
This is the code I have so far for the makefile:
chello: chello.o writeexit.o
ld -N chello.o writeexit.o -o chello
chello.o: chello.c
gcc -c chello.c -o chello.o
writeexit.o: writeexit.s
as writeexit.s -o writeexit.o
The whitespace before ld, gcc and as are all tabs, so I think the whitespacing is fine. When I call 'make makefile', it returns 'make: Nothing to be done for `makefile'.' However, if I change the dependencies of chello, like chello.c, the same message is returned and chello's behaviour is not modified.
From man make:
make executes commands in the makefile to update one or more target
names, where name is typically a program. If no -f option is present,
make will look for the makefiles GNUmakefile, makefile, and Makefile,
in that order.
make makefile will actually execute your "makefile" (because it is listed among the default names in the man page) file, trying to build the "makefile" target (because of the argument you are passing), which already exists
What you need is to build the "chello" binary, so you have to type:
make chello
Or alternatively:
make -f makefile chello
Alternative account here, it seems to work fine if I just call "make" instead of "make makefile". This question can be ignored.
All,
I'm trying to pass variables to make from the command line. My command is below
make ARCH=arm CROSS_COMPILE=/my_dir/bin/arm-openwrt-linux-g++
The error I received is
g++: error: arm: No such file or directory
But the file 'arm-openwrt-linux-g++' does exist.
I think the problem is I need to pass varibale to sub-make files. Can some help with an example of how to pass varialbes to sub-makefile from the command-line. I have tried using the -e and export options for make, but can't seen to get anything to work.
Thanks
Content of makefile:
# GNU Make solution makefile autogenerated by Premake
# Type "make help" for usage help
ifndef config
config=debug
endif
export config
PROJECTS := json openjaus
.PHONY: all clean help $(PROJECTS)
all: $(PROJECTS)
json:
#echo "==== Building json ($(config)) ===="
#${MAKE} --no-print-directory -C .build -f json.make
openjaus: json
#echo "==== Building openjaus ($(config)) ===="
#${MAKE} --no-print-directory -C .build -f openjaus.make
So, your problem is not related to sending variables over the command line.
Your problem is that in one of the makefiles in your sub-directories, which you haven't shown us, you're using the variable $(ARCH) in an incorrect way such that the expansion of the command line is not a legal g++ command line.
Based on the error message, most likely you're adding a space somewhere where it shouldn't be, so instead of something like -fmarch=arm you're getting -fmarch= arm. Obviously this is just an example because you didn't provide nearly enough information.
One other note: we can't know how your makefiles work but typically makefiles that support a variable like CROSS_COMPILE expect it to be set to just the prefix of the cross-compilation command; in your case it would be CROSS_COMPILE=/my_dir/bin/arm-openwrt-linux-. But, your makefiles might be different.
When asking questions, it's best to if you don't immediately jump to a guess about what the answer is. First describe the problem, and that includes showing the error line as well as a few lines before it. For example in this case you're getting an error from g++ so the command line that make printed out showing you how it invoked g++ would have helped greatly.
Once you've given the underlying detail, then if you think you have an idea about what the problem is go ahead and suggest it, and/or ask about it.
If you provide the rule that invokes g++ and/or the output from make showing the g++ command line, then we can help more.
Cheers!
Here's what I think needs to happen:
You need to make sure that your sub-makefiles actually respect the $(ARCH) and $(CROSS_COMPILE) variables. Are they also generated by Premake? If so, is that how it handles cross-compilation? Check the docs.
In my test (below), I found that variables set on the command line are propagated to sub-makes, which makes me think that your sub-makefiles aren't respecting $(ARCH):
Makefile:
a:
$(MAKE) -C z
z/Makefile:
a:
#echo "MAKE=$(MAKE)"
#echo "ARCH=$(ARCH)"
Running make with no arguments:
$ make
make -C z
make[1]: Entering directory `/home/foo/test/z'
MAKE=make
ARCH=
make[1]: Leaving directory `/home/foo/test/z'
Running make ARCH=bar:
$ make ARCH=bar
make -C z
make[1]: Entering directory `/home/foo/z/z'
MAKE=make
ARCH=bar
make[1]: Leaving directory `/home/foo/z/z'
Can I pass variables to a GNU Makefile as command line arguments? In other words, I want to pass some arguments which will eventually become variables in the Makefile.
You have several options to set up variables from outside your makefile:
From environment - each environment variable is transformed into a makefile variable with the same name and value.
You may also want to set -e option (aka --environments-override) on, and your environment variables will override assignments made into makefile (unless these assignments themselves use the override directive . However, it's not recommended, and it's much better and flexible to use ?= assignment (the conditional variable assignment operator, it only has an effect if the variable is not yet defined):
FOO?=default_value_if_not_set_in_environment
Note that certain variables are not inherited from environment:
MAKE is gotten from name of the script
SHELL is either set within a makefile, or defaults to /bin/sh (rationale: commands are specified within the makefile, and they're shell-specific).
From command line - make can take variable assignments as part of his command line, mingled with targets:
make target FOO=bar
But then all assignments to FOO variable within the makefile will be ignored unless you use the override directive in assignment. (The effect is the same as with -e option for environment variables).
Exporting from the parent Make - if you call Make from a Makefile, you usually shouldn't explicitly write variable assignments like this:
# Don't do this!
target:
$(MAKE) -C target CC=$(CC) CFLAGS=$(CFLAGS)
Instead, better solution might be to export these variables. Exporting a variable makes it into the environment of every shell invocation, and Make calls from these commands pick these environment variable as specified above.
# Do like this
CFLAGS=-g
export CFLAGS
target:
$(MAKE) -C target
You can also export all variables by using export without arguments.
The simplest way is:
make foo=bar target
Then in your makefile you can refer to $(foo). Note that this won't propagate to sub-makes automatically.
If you are using sub-makes, see this article: Communicating Variables to a Sub-make
Say you have a makefile like this:
action:
echo argument is $(argument)
You would then call it make action argument=something
From the manual:
Variables in make can come from the environment in which make is run. Every environment variable that make sees when it starts up is transformed into a make variable with the same name and value. However, an explicit assignment in the makefile, or with a command argument, overrides the environment.
So you can do (from bash):
FOOBAR=1 make
resulting in a variable FOOBAR in your Makefile.
It seems command args overwrite environment variable.
Makefile:
send:
echo $(MESSAGE1) $(MESSAGE2)
Example run:
$ MESSAGE1=YES MESSAGE2=NG make send MESSAGE2=OK
echo YES OK
YES OK
There's another option not cited here which is included in the GNU Make book by Stallman and McGrath (see http://www.chemie.fu-berlin.de/chemnet/use/info/make/make_7.html). It provides the example:
archive.a: ...
ifneq (,$(findstring t,$(MAKEFLAGS)))
+touch archive.a
+ranlib -t archive.a
else
ranlib archive.a
endif
It involves verifying if a given parameter appears in MAKEFLAGS. For example .. suppose that you're studying about threads in c++11 and you've divided your study across multiple files (class01, ... , classNM) and you want to: compile then all and run individually or compile one at a time and run it if a flag is specified (-r, for instance). So, you could come up with the following Makefile:
CXX=clang++-3.5
CXXFLAGS = -Wall -Werror -std=c++11
LDLIBS = -lpthread
SOURCES = class01 class02 class03
%: %.cxx
$(CXX) $(CXXFLAGS) -o $#.out $^ $(LDLIBS)
ifneq (,$(findstring r, $(MAKEFLAGS)))
./$#.out
endif
all: $(SOURCES)
.PHONY: clean
clean:
find . -name "*.out" -delete
Having that, you'd:
build and run a file w/ make -r class02;
build all w/ make or make all;
build and run all w/ make -r (suppose that all of them contain some certain kind of assert stuff and you just want to test them all)
If you make a file called Makefile and add a variable like this $(unittest)
then you will be able to use this variable inside the Makefile even with wildcards
example :
make unittest=*
I use BOOST_TEST and by giving a wildcard to parameter --run_test=$(unittest)
then I will be able to use regular expression to filter out the test I want my Makefile
to run
export ROOT_DIR=<path/value>
Then use the variable, $(ROOT_DIR) in the Makefile.