CFLAGS environment variable can be used to pass compilation switches to Makefile from the outside world without modifying the file itself. Is there a way to pass switches only for one specific source file?
In my case I'd like to suppress gcc warning for several files but not for all and the Makefile is automatically generated by IDE so I cannot edit it.
We can't answer this question given the lack of details.
However you can add NEW makefiles to be parsed along with the old makefiles, without changing the old makefiles. For example, you can run this:
make -f Makefile -f ExtraMakefile
and create your own ExtraMakefile that contains any extra makefile text you want and make will read them both, in that order.
Please find below way which will help you to pass extra compiler flags and assign value into it based on your conditions.
You can pass switches by creating a new variable , Ex: CCFLAGS_EXTRASWITCH and use this flag in CCFLAGS variable.
# Append CC_FLAGS with variable CCFLAGS_EXTRASWITCH which will be used to
# pass extra switches. Value of CCFLAGS_EXTRASWITCH you can assign
# to empty or some switches based on conditions/files that you have
CC_FLAGS = $(CCFLAGS_EXTRASWITCH) \
... \ # Other default compiler flags that already exists. Keep as it is
Related
This question already has an answer here:
Add compiler option without editing Makefile
(1 answer)
Closed 6 months ago.
Is there a way to suppress compiler warnings for GNU make and only show higher-order logs, i.e. errors?
Apparently, this should be possible using make -w as described here. However, for my version of GNU make (4.1), the man file specifies this as printing the current directory:
-w, --print-directory Print the current directory.
-W FILE
Consider FILE to be infinitely new.
If possible, this should be disabled both for make-internal warnings ($(warning ...)) and compiler-level warnings by gcc.
As pointed out in this post, it is not possible to directly add flags for the compiler. Furthermore, adding to existing CFLAGS variables (make CFLAGS+=-w) does not work either in most cases, as it ignores the append part and simply redefines the variable in the command line.
A very easy solution to fix this is by creating an empty dummy variable (once) inside your makefile and then defining it in case you need it:
# Add empty variable to add flags over command line
CDBG +=
CFLAGS += $(CDBG)
Which you then simply use as follows:
make CDBG=-w
as in https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
just add -w in your building command to suppress warnings, for example
gcc -Wall -w -o program pgmEcho.c pgm.c pgm.h
I am thinking I may need to use the file function in GNU make, and just can not follow the example they give. I have looked online, but don't see any post with more explanation. Here is the example they give:
program: $(OBJECTS)
$(file >$#.in,$^)
$(CMD) $(CMDFLAGS) #$#.in
#rm $#.in
I think I know what it is doing at a high level as it is explained in the manual.
$#.in
is a list of all the target files
$^
is a list of the source files
I am not sure how #$#.in is used on the third line or what there is an # sign at the beginning. What does that mean please? What does it supposed to do?
The key to the operation of that recipe is given in the prose immediately preceding it in the manual:
Many commands use the convention that an argument prefixed with an # specifies a file containing more arguments. Then you might write your recipe in this way:
program: $(OBJECTS)
$(file >$#.in,$^)
$(CMD) $(CMDFLAGS) #$#.in
#rm $#.in
$# is the target file (there is only one of those in any given recipe)
$#.in is the target file with .in added to the end of the name.
$^ is the "list" of the all the prerequisites of the target.
#$#.in is the name of the target with .in at the end and # at the start.
So the $(file ...) call in that recipe writes the list of prerequisites of the target into a file called program.in in "overwrite" mode and then passes that file name to the $(CMD) command using the #filename convention that was mentioned.
Is there a way to specify, in a .pro file, extra commands to be added to a standard target in the Makefile that qmake generates? For example, consider distclean, extra commands might be desired to:
Remove *~ files.
Clean out runtime-generated output files from the source tree.
Etc.
I want to use the normal target and not a custom target because I want this to be completely transparent in my workflow. That is (again using distclean as an example), I don't want to...
... require knowledge in a multi-project setup that certain Makefiles use a custom rule instead of distclean.
... document custom rules, even for stand-alone projects, as distclean is already well-known and intuitive†.
I found How to add custom targets in a qmake generated Makefile?, but this describes adding custom targets (which is already documented, even back in 4.6) rather than adding rules to existing targets. While it does contain some hints, all of them require adding new custom targets, as specifying the same target more than once in a Makefile replaces (not adds) commands from the previous target.
The only thing I could really think of to try was to add target.commands += new commands to the .pro file as a wild guess (e.g distclean.commands += rm \"*~\"). This has no effect.
How can I transparently add custom commands to existing targets with qmake?
† For the distclean example: While maintainer-clean is also on that "standard target" list, in practice I have found it to be rarely used, and in any case qmake doesn't generate it by default; I consider it to be unsuitable.
There are two straightforward ways to accomplish this, depending on how self-contained / portable you want your solution to be and how lenient you want to be with the order of command execution.
Option 1
The first option is to create a custom target in the .pro file for the new commands, then add that target as a prerequisite to the standard target that you are modifying. Going back to the distclean example, let's say you want to add a command to remove all *~ files:
Create a custom target in your .pro file. Note that you have to escape quotes and slashes in .pro files. For example, add:
extraclean.commands = find . -name \"*~\" -exec rm -v {} \\;
Add this target as a dependency of the target you are modifying:
distclean.depends = extraclean
This won't actually modify the distclean rule just yet, as this method can't be used to modify existing rules. However...
Add both your new target and the target you are modifying as extra targets:
QMAKE_EXTRA_TARGETS += distclean extraclean
This will add a second specification of distclean to the Makefile, but this works because you can add dependencies to existing targets in make in separate rules, even though you can't add commands that way. If you were to also specify distclean.commands in your .pro file, you would break the existing distclean by replacing its default recipe.
So, putting that all together, in the .pro file:
extraclean.commands = find . -name \"*~\" -exec rm -v {} \\;
distclean.depends = extraclean
QMAKE_EXTRA_TARGETS += distclean extraclean
Where extraclean is some custom target with the commands you want to add, and distclean is the existing target that you wish to modify.
Pros:
Completely self-contained in a .pro file.
As portable as you can get, leaves the actual Makefile syntax and generation up to qmake.
Cons:
Your new commands aren't appended to the existing recipe. Rather, they happen after all prerequisite targets are satisfied but before the existing recipe. In the distclean example, with the version of qmake that I'm using, this places the commands after the source tree clean but before Makefile itself is deleted (which is the only action the default recipe takes). This is not an issue for this example, but may be an issue for you.
Option 2
The second option is to change the name of the Makefile that qmake generates, and create your own custom Makefile that defers to the generated one, rather than includes + overrides it. This is also a straightforward option; while not as self-contained as option 1, it gives you the ability to execute commands both before and after the default generated recipe.
You don't want to include + override the existing Makefile, because you don't want to replace the default recipes. If you do, you have to re-implement the default, but this can be an issue as that default may change (and you have to keep up with the changes). It's best to let qmake do as much work as possible, and not repeat its work.
To do this:
First, change the name of the file that qmake generates. This can be accomplished by adding a line such as this to the .pro file:
MAKEFILE = RealMakefile
That will cause qmake to output RealMakefile instead of Makefile.
The next step is to create your own Makefile with your custom commands. However, there are some caveats here. First, a full example, again using distclean. In a file named Makefile:
.DEFAULT_GOAL := all
%:
#$(MAKE) -f RealMakefile $#
distclean:
#$(MAKE) -f RealMakefile $#
#find . -name "*~" -exec rm -v {} \;
Some notes about this:
We set .DEFAULT_GOAL because otherwise distclean would be the default. An alternative to this, if you're not comfortable with .DEFAULT_GOAL, is to specify an all rule using #$(MAKE) -f RealMakefile $# as the recipe.
The % target matches any target that isn't otherwise defined in this Makefile. It simply delegates processing to RealMakefile.
The distclean target is where we add our commands. We still need to delegate to RealMakefile, but additional commands can be added both before and after that happens.
Pros:
More control over command order. Commands can be added both before and after the default recipe.
Cons:
Not self-contained in a .pro.
Not as portable: It doesn't leave all Makefile generation up to qmake, and also I'm not actually sure what parts are specific to GNU make here (comments welcome).
So, while this answer may be a little long, both of these methods are very straightforward. I would prefer option 1 unless the command execution order is an issue.
Another solution is to add files you want to delete to the QMAKE_CLEAN and QMAKE_DISTCLEAN qmake variables.
build_tests {
TINYORM_SQLITE_DATABASE = $$quote($$TINYORM_BUILD_TREE/tests/q_tinyorm_test_1.sqlite3)
QMAKE_CLEAN = $$TINYORM_SQLITE_DATABASE
QMAKE_DISTCLEAN = $$TINYORM_SQLITE_DATABASE
}
It is relevant only, when do you know files you want to delete, so in this case, you can not use rm command or some sort of globbing.
I would like to have a makefile like this:
cudaLib :
# Create shared library with nvcc
ocelotLib :
# Create shared library for gpuocelot
build-cuda : cudaLib
make build
build-ocelot : ocelotLib
make build
build :
# build and link with the shared library
I.e. the *Lib tasks create a library that runs cuda directly on the device, or on gpuocelot respectively.
For both build tasks I need to run the same build steps, only creating the library differs.
Is there an alternative to running make directly?
make build
Kind of a post-requisite?
Note: This answer focuses on the aspect of a robust recursive invocation of a different target in a given makefile.
To complement Jack Kelly's helpful answer, here's a GNU makefile snippet that demonstrates the use of $(MAKE) to robustly invoke a different target in the same makefile (ensuring that the same make binary is called, and that the same makefile is targeted):
# Determine this makefile's path.
# Be sure to place this BEFORE `include` directives, if any.
THIS_FILE := $(lastword $(MAKEFILE_LIST))
target:
#echo $# # print target name
#$(MAKE) -f $(THIS_FILE) other-target # invoke other target
other-target:
#echo $# # print target name
Output:
$ make target
target
other-target
Using $(lastword $(MAKEFILE_LIST)) and -f ... ensures that the $(MAKE) command uses the same makefile, even if that makefile was passed with an explicit path (-f ...) when make was originally invoked.
Note: While GNU make does have features for recursive invocations - for instance, variable $(MAKE) specifically exists to enable them - their focus is on invoking subordinate makefiles, not on calling a different target in the same makefile.
That said, even though the workaround above is somewhat cumbersome and obscure, it does use regular features and should be robust.
Here is the link to the manual section covering recursive invocations ("sub-makes"):
Recursive Use of make
Most versions of make set a variable $(MAKE) that you can use for recursive invocations.
As you have written it, the build target will need to do something different depending on whether you have just done an ocelot or cuda build. That's another way of saying you have to parameterise build in some way. I suggest separate build targets (much like you already have), with associated variables. Something like:
build-cuda: cudaLib
build-ocelot: ocelotLib
build-cuda build-ocelot:
shell commands
which invoke ${opts-$#}
On the command-line you type make build-cuda (say). Make first builds cudaLib, then it carries out the recipe for build-cuda. It expands the macros before calling the shell. $# in this case is build-cuda, thus ${opts-$#} is first expanded to ${opts-build-cuda}. Make now goes on to expand ${opts-build-cuda}. You will have defined opts-build-cuda (and of course its sister opts-build-ocelot) elsewhere in the makefile.
P.S. Since build-cuda et. al. are not real files, you had better tell make this (.PHONY: build-cuda).
How do I set the LD_LIBRARY_PATH env variable from a Makefile?
I have some source code that links to a shared library that in turn links to a different shared library (more than 1). The Makefile for building the application only knows about the first shared library.
If I want to build this, I have to specify:
#export LD_LIBRARY_PATH=/path/to/the/shared/libs (for bash)
and that works fine.
However, I would like to do this from the Makefile itself.
Yes, "export" is the correct directive to use. It is documented in detail here. This is the same mechanism as make itself uses to propagate variables to sub-makes. The drawback is that you cannot selectively pass down the variable to some commands and not to others.
There are two other options I can think of:
Using .EXPORT_ALL_VARIABLES (specify as a target somewhere), causes all variables to be exported to the environment of sub-commands.
Specify on the command line:
foo:
EXPORTEDVAR=somevalue gcc $< -o $#
If you don't want to export the LD_LIBRARY_PATH variable within the makefile (e.g. because you have recursive Makefiles which all add to the variable), you can keep it bound to all calls to your compiler and linker.
Either you add it directly to all gcc and ld calls within your target rules, e.g.
my_target: my_target.o
LD_LIBRARY_PATH=/my/library/path gcc -o my_target my_target.o
or you set the global make variables that define the compilers include the path, e.g.:
CC=LD_LIBRARY_PATH=/my/library/path gcc
CPP=LD_LIBRARY_PATH=/my/library/path gcc
CXX=LD_LIBRARY_PATH=/my/library/path gcc
I chose gcc as compiler but of course you can use any compiler you like.
I had the same problem, I had to export LD_LIBRARY_PATH as you did:
export LD_LIBRARY_PATH=/path/to/the/shared/libs ; my_command
My friend showed me an alternative when LD_LIBRARY_PATH only applies to one command, notice no semicolon below.
LD_LIBRARY_PATH=/path/to/the/shared/libs my_command
This article explains more.
I had tried adding:
export LD_LIBRARY_PATH=/path/to/the/shared/libs
which apparently works fine.
I was getting errors because my /path/to/the/shared/libs was incorrect.
Would still be good to know what others do for this and/if there is a better way.
If you want to set LD_LIBRARY_PATH for a particular make , try this LD_LIBRARY_PATH=/path/to/the/shared/libs make.
Adding this to the top of the Makefile worked for me:
export LD_LIBRARY_PATH := $(HOME)/lib
Pay attention not to add any extra spaces to the end of the line. I wasted some time until I realized that was the problem.