In my current project, more than 200MB C files are present. While making targets I can able to see only < 100MB is used to create a binary. How, to identify what are the files are not touched while creating targets. So, that we can strip it off and make the codebase more sleek.
How, to identify the list of files created for target while compiling?
I think the best approach is to use one of the methods Linux offers for monitoring file system access:
inotifywait
kfsmd
loggerfs
auditd / auditctl / ausearch
You could also run the make command with strace (strace -f make) and parse the output for open() calls.
That is what I used to do in the past.
Take your pick.
I would probably:
make clean
make 2>out to capture the full log of the build to a file
grepthe out file for gcc invocations
Filter out the filenames from the gcc invocations
Build a sorted list of those filenames
Build a sorted list of filenames in the project.
Compare the two.
Or something like that. Shouldn't be too hard.
Another method is to open the (autogenerated) dependency files for you executables and shared libraries. They are going to contain .o as prerequisites, which normally correspond to .c.
This works best for non-recursive make build systems with complete dependency trees.
If your make is GNU make, as seems likely, you could consider
variations on the following approach. (For simplicity I'll assume that the only
source files of interest are .c files.)
Say we have Makefile in directory dir that makes some default
target and possibly others, including intermediate targets.
You can use another makefile, say, unused_srcs.mk that you include in
Makefile, such that in dir you can run:
make unused_srcs
which will display a list of all the source files in dir that don't
contribute to the default target. Or run:
make unused_srcs target=TARG
for some target TARG, and get a list of all the source files in dir that
don't contribute to TARG.
This assumes that Makefile has a clean target, or maybe several
variants of clean[-???], that can suitably clean the default target or
any target you might be interested in, and that you don't mind
a suitable clean[-???] being invoked for the unused_srcs target.
For example, in dir we have:
main.c
extern void boo(void);
int main(void)
{
boo();
return 0;
}
boo.c
#include <stdio.h>
void boo(void)
{
puts("Boo!");
}
noop.c
void noop(void){}
Makefile
.phony: all clean
all: boo
objs = main.o boo.o
boo: $(objs)
gcc -o $# $^
clean-obj:
rm -f *.o
clean: clean-obj
rm -f boo
# include /some/standard/place/unused_srcs.mk
include unused_srcs.mk
And in some standard place which, for simplicity, we'll assume is again dir,
we have:
unused_srcs.mk
.phony: unused_srcs
ifndef $(target)
target = all
endif
ifndef $(cleaner)
cleaner = clean
endif
all_srcs = $(wildcard *.c)
used_srcs = $(filter %.c,$(shell ($(MAKE) $(cleaner) && $(MAKE) -n -d $(target)) \
| grep -e 'Considering target file' | sed -e "s/[\`\']//g" -e "s/\.$$//g" -))
unused_srcs = $(filter-out $(used_srcs),$(all_srcs))
unused_srcs:
#echo $(unused_srcs)
In this project:-
noop.c is unused by boo (it is completely superfluous)
noop.c and main.c are unused by boo.o
noop.c and boo.c are unused by main.o
And we can discover such facts with make unused_srcs commands:
$ make unused_srcs
noop.c
$ make unused_srcs target=boo
noop.c
$ make unused_srcs target=boo.o
main.c noop.c
$ make unused_srcs cleaner=clean-obj target=boo.o
main.c noop.c
$ make unused_srcs target=main.o
boo.c noop.c
$ make unused_srcs target=clean
boo.c main.c noop.c
Clearly all the heavy-lifting is done in the evaluation of $(used_srcs)
and $(unused_srcs) in unused_srcs.mk, and mostly the former.
The evaluation of $(used_srcs) exploits GNU make's -d option, which
generates fulsome debugging info, together with the fact that any source
file that does contribute to the chosen TARG must itself be considered
a potential target when TARG is made.
Together, these things mean that if we clean TARG and then run make -n -d TARG
the output will be the debugging info of a dry-run (-n) of make TARG,
and in this output a line like:
Considering target file `FILE.c'.
will appear for each .c file FILE.c that contributes to TARG, and
for no other .c files that may be present.
The evaluation of $(used_srcs) generates that debugging info and filters
it to extract the names of the .c files.
The evaluating of $(unused_srcs) then just weeds out the $(used_srcs)
from the list of all the .c files there are.
Related
I am customizing my Makefile for a school project.
I would like to print the following sentence but only when the .c files from my SRCS_DIR have been actually compiled.
All the .c files have been compiled successfully !
If I move the printf that you see in line 3 of the code block below to the last line, it prints the message after each .c file being compiled...
Thus, I created a COMPILED variable which I set to 0 at the beginning of my Makefile, and then I change its value to 1 during compilation (line 11 in the code block below). I tried to use the ifeq condition (line 2 in the code block below), but the sentence does not print when I do that.
$(NAME): $(LIBFT_AR) $(OBJS)
ifeq ($(COMPILED), 1)
printf "$(GREEN)> All the .c files have been compiled successfully !$(END)\n"
endif
printf "$(BLUE)> Creating the executable file :$(END) $#\n"
$(CC) $(OBJS) $(LIBFT_AR) -lreadline -o $(NAME)
printf "$(GREEN)> Executable file has been created successfully !$(END)\n"
$(OBJS_DIR):
mkdir -p $(addprefix $(OBJS_DIR)/, $(SUBDIRS_LST))
$(OBJS_DIR)/%.o: $(SRCS_DIR)/%.c $(INCS) Makefile | $(OBJS_DIR)
override COMPILED=1
$(CC) $(CFLAGS) -I $(INCS_DIR) -c $< -o $#
printf "$(BLUE)> Compiling :$(END) $<\n"
Do you have any explanation regarding this issue and/or a solution that could help me to solve the problem ?
Thank you !
Makefiles are not scripting languages. Make doesn't read the makefile and run each rule as it's read. Make will (1) parse the entire makefile (and any included files) and build an internal graph of all the prerequisites, than (2) run recipes for targets that are outdated. Content that is NOT IN A RECIPE is always evaluated during the first step. Content that IS IN A RECIPE is always evaluated during the second step.
Lines that are not indented with TABs, are not in recipes (and so are evaluated during the first step). Lines that are indented with TABs, are in recipes (and so are evaluated--which means, given to the shell to execute--during the second step).
Maybe you can now see why your attempts cannot work: the if-statements and variable assignment of COMPILED are always evaluated, during the first step, before make has decided whether or not any targets should be built.
I'm not really sure I understand your goal. If the recipe of your executable is being invoked then it means that all your source files have been compiled: that's what a makefile does. Maybe you are trying to make a distinction between a build where at least one source file was compiled, and a build where no source files had to be recompiled but the target (the executable) was out of date?
If that's what you want the simple way to solve your problem is with automatic variables; for example the $? automatic variable expands to the list of prerequisites that were out of date. You can do something like:
$(NAME): $(LIBFT_AR) $(OBJS)
test -z '$(filter %.o,$?)' || printf "$(GREEN)> All the .c files have been compiled successfully !$(END)\n"
printf "$(BLUE)> Creating the executable file :$(END) $#\n"
$(CC) $(OBJS) $(LIBFT_AR) -lreadline -o $(NAME)
printf "$(GREEN)> Executable file has been created successfully !$(END)\n"
The $(filter ...) function will expand to the list of .o files in the $? variable; if that's empty then no .o files were rebuilt.
I am trying to create a makefile, for the first time. I went through some tutorials and I managed to create one, but I am having trouble with a couple of things. Below are the details.
Below are the files in the order of execution:
CSV_to_txt.c - no dependency on any other files.
I want to include CSV_files/Equilibrium_trajectories.csv, which is my input, in the make file. Further, I run the command tac Chemical_Equilibrium.txt in the terminal. Can I include this in the make file as well?
fluid_profile.c - depends on pdfutil.h and beta_util.h.
I have the same problem of reading the inputs, for ex:
Enter the number of points
1000 --> to be included in the make file.
This file creates a text file called fluid_points.txt. What I want to include in the makefile is if this file already exists don't execute the command gcc fluid_points.c -o fluid_points.o -lm.
Structure of the make file:
all:
gcc CSV_to_txt.c -o CSV_to_txt.o -lm
./CSV_to_txt.o
#Include the file path and name when asked for it
#ubuntu terminal command --> tac filename.txt > filename_changed.txt
gcc fluid_profile.c -o fluid_profile.o -lm
./fluid_profile.o
#Enter the number of points when prompted to do so
#If fluid_points.txt file is already existing don't execute the above command, instead execute the below one
gcc blah.c -o blah.o -lm
./blah.o
clean:
$(RM) *.o *~
Any sort of help or even a link to a tutorial would be helpful.
A suggested makefile:
run:
.PHONY: run
CSV_to_txt: CSV_to_txt.c
gcc CSV_to_txt.c -o CSV_to_txt -lm
fluid_profile: fluid_profile.c
gcc fluid_profile.c -o fluid_profile -lm
blah: blah.c
gcc blah -o blah.c -lm
run: CSV_to_txt fluid_profile blah
echo "CSV_files/Equilibrium_trajectories.csv" | ./CSV_to_txt.o
tac Chemical_Equilibrium.txt
echo "1000" | ./fluid_profile.o
./blah.o
clean:
$(RM) *.o *~
So, a break down -- first line, predeclare target run, such that it becomes the default target (if you do make, it will run the first target ). Declare this as a phony target (This means there's no actual file called run being produced. You can look up .PHONY for more details)
Then create some rules to generate the executables. Each executable has its own rule to generate it. Typically you would use automatic variables for these like $# and $<, but I wanted to keep it simple for now.
Then the rule for run. This is dependent on the executables (so executables will finish building before this rule runs).
Then, to pass the filename into the executable, you can simply echo the filename, and then pipe that into the executable.
You have a common newbie error... this is to think that a source file depends on other source files (a .c file depends on some .h files) This is an error and probably the cause you are not getting your result.
The objective of a Makefile is to describe file dependencies in order to do the minimum set of commands to build the final target you specify. For this you need to think that a target is something you are goint to create.
Is a source .c file something you create during the build proces? Not, so it cannot be a target of a rule. The target, indeed is the result of the compilation. The source file doesn't depend on a header file... it just includes it to make the compilation of the .o target (this is, actually the target).
Let's say you have a program hello.c that includes modA.h and modB.h. (and even modB.h includes modB2.h) If you modify any of them, you need to recompile hello.c, so your rule will be:
# (1)
hello.o: hello.c modA.h modB.h modB2.h
cc -c hello.c # (2) see below.
(1) a rule line starts at column 1 and has a left hand side (the target file) and a list of sources (dependencies). Each time make sees that the target doesn't exist or has a last change date earlier than the change dates of any of the dependencies, the command lines below are executed, one after the other.
(2) a command rule starts with a <tab> char in the first column of the line. It represents a command (or a list of commands, each in it's command line) that are required to generate the target file from the sources.
a line starting with # is a comment line (also valid to start in the middle of a rule or a command line)
There is anothe type of line (a macro definition) but you need to learn first how to create dependencies and get used to them, before starting learning how to create macros. Read the make(1) doc first.
you see that we only compile hello.c, but we have to do it every time we change any of the other files above. There are two modules, modA.o and modB.o, each of them with their .c file and the includes needed in hello.c. So:
modA.o: modA.c modA.h
cc -c modA.c
modB.o: modB.c modB.h modB2.h
cc -c modB.c
so when we change any of modA.c or modA.h then modA.o will be created. And as modB.h we said above that included modB2.h, then if we modify it, it should be compiled.
Now the dependency of the program to be linked: As the program is compiled, it has just three modules: hello.o, modA.o and modB.o. To create hello all these three modules must be given to the linker.... so the Makefile needs also:
hello: hello.o modA.o modB.o
cc -o hello hello.o modA.o modB.o
and so, the complete Makefile is:
# this rule is put first to become the default target.
# the default target is the final program.
hello: hello.o modA.o modB.o
cc -o hello hello.o modA.o modB.o
# this rule is for the hello.o target only.
hello.o: hello.c modA.h modB.h modB2.h
cc -c hello.c
# this rule is for modA.o
modA.o: modA.c modA.h
cc -c modA.c
# and this one for modB.o
modB.o: modB.c modB.h modB2.h
cc -c modB.c
and with this Makefile you'll enjoy, because you can touch any file, but the compiler will compile only the correct dependencies to generate the final executable program.
Make has a lot of more functionality, but that requires you to know at least the most basic of it. Once after you have succeeded on the creation of the correct dependencies, you can start to study the other facilities of make, that are only there to abbreviate/avoid rewritting the same thing several times. But read at least the make manual page.
I'm trying to get libtool and yasm to work together.
yasm creates the correct .o files from my .asm sources, but I can't figure out how to get libtool to build the associated .lo and .dep files.
It wants to build the shared library, incorporating the .o files.
libtool generated files typically use the following layout: The .lo file in a build directory consisting of location metadata; the static object .o files in the build directory; and the PIC / shared .o objects in the build/.libs directory.
You can use the libtool compile mode. I'm not familiar with yasm, so you'll have to fill in the switches. It will run the yasm build twice, once with -DPIC (and maybe other shared object options).
libtool --tag=CC --mode=compile yasm <options> src.asm
If using automake, this may require an explicit rule for the .asm files:
.asm.lo:
$(LIBTOOL) --tag=CC --mode=compile \
yasm <options> $<
Keep in mind that those are TABs in Makefiles, not (8) space characters!
You might also need to add: .SUFFIXES: .asm .lo prior to this. I use the variable $(LIBTOOL), because some platforms (OSX for example) need to install it as glibtool, and it's what Makefile.indoes.
The generated src.lo, src.o, .libs/src.o should be respected by make clean for example.
For your library libfoo, you will need to let automake know about these sources with: EXTRA_libfoo_la_SOURCES = src.asm, and obj deps with libfoo_la_LIBADD = src.lo. It might be even be worthwhile adding to dependencies: libfoo_la_DEPENDENCIES = src.lo.
Though I don't see why just putting src.asm in libfoo_la_SOURCES wouldn't be sufficient.
This works (although I never did figure out how to get libtool to create the .lo file in the target directory, or to create the target directory's .libs directory).
The Makefile rule:
# Rule to build object files from asm files.
#
# XXX
# Libtool creates the .lo file in the directory where make is run. Move the file
# into place explicitly; I'm sure this is wrong, but have no idea how to fix it.
# Additionally, in a parallel make, the .libs file may not yet be created, check
# as necessary, but ignore errors.
.asm.lo:
-d=`dirname $#`; test $d/.libs || mkdir $d/.libs
$(LIBTOOL) --tag=CC --mode=compile sh $(srcdir)/dist/yasm.sh $< $#
rm -f $#
mv `basename $#` $#
A support shell script to do the yasm call:
#! /bin/sh
# Libtool support for yasm files, expect the first argument to be a path to
# the source file and the second argument to be a path to libtool's .lo file.
# Use the second argument plus libtool's -o argument to set the real target
# file name.
source=$1
target=`dirname $2`
while test $# -gt 0
do
case $1 in
-o)
target="$target/$2"
shift; shift;;
*)
shift;;
esac
done
yasm -f x64 -f elf64 -X gnu -g dwarf2 -D LINUX -o $target $source
I am working on a C project which contains around 200 .c files and some .h files. Not all of these 200 files are required in the final product. Currently around 180 files needs to be compiled. We have a file "compile_only_these.c" which includes these 180 *.c files required for the project. Our makefile compiles only this file instead of individual .c files.
/* file: compile_only_these.c*/
#include "file1.c"
#include "file2.c"
.
.
.
#include "file180.c"
But I think including .c files is a bad idea. Because every time I modify any of these files, all files are compiled again.
Can you suggest a better way to compile these files.
More info:
All .c files are in same folder "../project/src"
I keep adding new .c files which are required to be compiled. I dont want to modify Makefile every-time I add a new file.
I still want to keep those 20 .c files which I am not compiling right now. I may use it in future. Deleting these files are moving them to other directory is not a solution
What you need is a variable in the makefile, a list of required object files, like this:
OBJS := file1.o file2.o ... file180.o
You can have Make construct it from the compile_only_these.c file like this:
OBJS := $(shell sed -e '/\#include/!d' -e 's/\#include "\(.*\)\.c"/\1.o/' compile_only_these.c)
Do you also need a hand with the rule that uses these objects to construct the final product?
As already mentioned, it's sort of a weird way to manage a project, but given what you have to work with, you might try something along this approach...
CC = gcc
OBJFILE = myprog
# Tweak to match whatever you compile with normally
CFLAGS = -O2 -Wall -std=c89 -pedantic
LDFLAGS= # Extra flags here, for example -lm -pthread
RM = rm -f
SRCS = $(wildcard *.c)
OBJS = $(SRCS:.c=.o)
$(OBJFILE):$(OBJS)
$(CC) -o $# $^ $(LDFLAGS)
clean:
$(RM) core *~ $(OBJS) $(OBJFILE)
You will obviously need to adjust the path(s) for the specifics of your build hierarchy if you want to do more in your make than just compile this list of files, but this is a general approach for grabbing all files with wildcard substitution.
I have the following Makefile.am which is supposed to create foo.hdb and foo.cdb from foo.h (via the Python script):
TESTS = check_foo
check_PROGRAMS = check_foo
check_foo_SOURCES = check_foo.c $(top_builddir)/src/isti.h \
foo.cdb foo.h foo.hdb
check_foo_CFLAGS = #CHECK_CFLAGS# $(all_includes) -I../../clib/src/
check_foo_LDADD = $(top_builddir)/src/libcorm.la #CHECK_LIBS# -lsqlite3
%.hdb %.cdb: %.h
PYTHONPATH=$(top_builddir)/cgen/src python $(top_builddir)/cgen/src/isti/cgen/run.py $<
clean-local:
rm -f *.hdb *.cdb
However, although make foo.hdb and make foo.cdb work (call the Python code and generates the foo.hdb and foo.cdb files from foo.h), make clean check (or the two separately) does not (missing foo.hdb - no such file) - the pattern rule is not called to generate foo.hdb from foo.h.
In other words: the pattern rule is not being called for the files listed in check_foo_SOURCES.
How can I make this work? The rest of the autotools infrastructure is working fine. From looking at the Makefile I suspect the issue is with how autotools expands the check sources.
This is all on Linux with Gnu make. Here is the Makefile.
[Updated slightly to reflect the help from MadScientist].
Later update
The following Makefile (just make, not autotools) works fine, so the issue seems to be related to autotools and check support.
all: check_foo
CFLAGS=-I../../clib/src
LDFLAGS=-L../../clib/src/.libs
check_foo: check_foo.c foo.h corm_foo.h corm_foo.c
gcc $(CFLAGS) $(LDFLAGS) $^ -o $# -lcorm -lsqlite3
corm_%.h corm_%.c: %.h
PYTHONPATH=../../cgen/src python ../../cgen/src/isti/cgen/run.py $<
clean:
rm -f corm_*.h corm_*.c
rm -f *.o
(Note that I've switched from xxx.hdb to corm_xxx.h, etc, so that file extensions remain OK).
More Details
Since it seems to be related to the CHECK macros, this is configure.ac:
AC_INIT([corm], [0.1], [a.cooke#isti.com])
AC_CONFIG_MACRO_DIR([m4])
PKG_CHECK_MODULES([CHECK], [check >= 0.9.4])
AM_INIT_AUTOMAKE([-Wall foreign -Werror])
AC_PROG_CC_C99
AM_PROG_CC_C_O
LT_INIT
AC_CONFIG_HEADERS([config.h])
AC_CONFIG_FILES([Makefile clib/Makefile clib/src/Makefile clib/tests/Makefile clib/docs/Makefile cgen/Makefile cgen/docs/Makefile example/Makefile example/src/Makefile])
AC_CHECK_PROGS([DOXYGEN], [doxygen], AC_MSG_WARN([Doxygen not found - continuing without Doxygen support]))
AM_CONDITIONAL([HAVE_DOXYGEN], [test -n "$DOXYGEN"])
AM_COND_IF([HAVE_DOXYGEN], [AC_CONFIG_FILES([clib/docs/Doxyfile cgen/docs/Doxyfile])])
SOLUTION
OK, so summarizing the various things below, there were two important issues (once I had fixed file extensions - see the "plain" makefile and fceller's answer), either one of which was sufficient to make things work:
(The handling of) Header files is complicated. Because of auto-dependencies, programatically generated header files break things. The solution is to use BUILT_SOURCES
But (the handling of) .c files is not complicated. So putting the corm_foo.c in front of check_foo.c would trigger the generation of that file. Since that also generates corm_foo.h, everything works (because check_foo.c now can include corm_foo.h).
Also, fceller has some good general points about tidy makefiles and explains why the "plain" makefile works.
The line
%.cdb: %.hdb
does not do anything. Check the GNU make manual and you'll see that a pattern rule without a command line is used to DELETE a previously defined rule with that same pattern. Since there's no previous rule, this is essentially a no-op.
If you have a command that creates TWO output files with ONE invocation of a rule, then you need to put both patterns in the same rule, like this:
%.cdb %.hdb: %.h
PYTHONPATH=$(top_builddir)/cgen/src python $(top_builddir)/cgen/src/isti/cgen/run.py $<
This will tell GNU make that both targets are generated from one invocation of the rule. BE AWARE! This syntax only has this behavior for pattern rules. Explicit rules with multiple targets do something entirely different (confusingly enough).
As for the make clean behavior, I'm not sure. The makefile generated by automake is too complex for me to just read it; it would require some debugging (run it and trace what happens). However, I suspect that the rules there are not designed properly to allow a clean target and a build target to both be run in the same invocation of make. Run the two commands separately and see if that works better:
make clean
make check
You need to tell automake that foo.hdb is a source file that is to be constructed. Add the following to Makefile.am:
BUILT_SOURCES = foo.hdb
First of all: you do not need to include the "*.h" in *_SOURCES. The automake will generated code to generate the dependencies. From the manual: Header files listed in a _SOURCES definition will be included in the distribution but otherwise ignored
The change you made in the plain Makefile ("Note that I've switched from xxx.hdb to corm_xxx.h, etc, so that file extensions remain OK") is essential. The automake FILTERS the *_SOURCES list using the filename extension in order to see what to call (CC, CXX, F77).
The following Makefile.am will work:
TEST = check_foo
check_PROGRAMS = check_foo
check_foo_SOURCES = check_foo.c foo.db.c
check_foo_CFLAGS =
check_foo_LDADD =
%.db.c %.db.h: %.h
echo "int i = 1;" > foo.db.c
echo "int j;" > foo.db.h
clean-local:
rm -f *.db.h *.db.c
Let me try to add an indirect answer/discussion to the existing direct ones.
I recently moved away from make for the same kind of reasons you experienced: it is extremely powerful but sometimes a bit difficult to debug when things do not go as expected.
I recently discovered pydoit which is very promising as a debuggable replacement build tool for make. Since the notion of "pattern rules" was not present in it, I proposed an independent package to do the job: fprules.
This is how you would perform the same task that you mention in your post, with doit and fprules:
from fprules import file_pattern
# all: check_foo
DOIT_CONFIG = {'default_tasks': ['check_foo']}
CFLAGS = '-I../../clib/src'
LDFLAGS = '-L../../clib/src/.libs'
# check_foo: check_foo.c foo.h corm_foo.h corm_foo.c
# gcc $(CFLAGS) $(LDFLAGS) $^ -o $# -lcorm -lsqlite3
def task_check_foo():
"""
Compiles the `check_foo` executable
"""
src_files = ('check_foo.c', 'foo.h', 'corm_foo.h', 'corm_foo.c')
dst_file = 'check_foo'
return {
'file_dep': src_files,
'actions': ["gcc %s %s %s -o %s -lcorm -lsqlite3" % (CFLAGS, LDFLAGS, ' '.join(src_files), dst_file)],
'verbosity': 2,
'targets': [dst_file],
'clean': True
}
# corm_%.h corm_%.c: %.h
# PYTHONPATH=../../cgen/src python ../../cgen/src/isti/cgen/run.py $<
def task_gen_corm():
"""
Generates files `corm_%.h` and `corm_%.c`
for each header file `%.h`.
"""
for data in file_pattern('./*.h', dict(h_file='./corm_%.h', c_file='./corm_%.c')):
yield {
'name': data.name,
'file_dep': [data.src_path],
'actions': ["PYTHONPATH=../../cgen/src python ../../cgen/src/isti/cgen/run.py %s" % data.src_path],
'verbosity': 2,
'targets': [data.h_file, data.c_file],
'clean': True
}
# clean:
# rm -f corm_*.h corm_*.c
# rm -f *.o
# No need to create tasks for this:
# with 'clean': True, `doit clean` will clean all target files
Then simply run doit in the folder.
Do not hesitate to provide feedback on the projects pages if needed: for example multiline commands are not supported, you can vote for them if you too feel that they are missing: https://github.com/pydoit/doit/issues/314