Need your help with projecting the makefile. So, what I have and what I want to get. I need to build two executables. Source code is common. Preprocessor macros control differences for both exes, for example, in main.cpp:
#if PROJECT_TYPE==FTP
std::cout << "FTP" << std::endl;
#else
std::cout << "SFTP" << std::endl;
#endif
Differences aren't only in source code but also in additional libraries that used for linking:
FTP_LDFLAGS= -static-libstdc++ -static-libgcc -s -L $(ROOT_DIR)/lib/Release -l:libboost_thread-mgw46-mt-1_49.a -l:libcommon.a \
-l:libfile.a -l:libfilesearcher.a -l:libftpclient.a -l:libftplib.a -l:libdbclient.a -l:libsqlite3.a -l:libscheduler.a -l:libws2_32.a
SFTP_LDFLAGS= -static-libstdc++ -static-libgcc -s -L $(ROOT_DIR)/lib/Release -l:libboost_thread-mgw46-mt-1_49.a -l:libcommon.a \
-l:libfile.a -l:libfilesearcher.a -l:libdbclient.a -l:libsqlite3.a -l:libscheduler.a -l:libsftpclient.a -l:libws2_32.a -l:libssh.dll
Also I want to create debug/release build targets with own CXXFLAGS and output directories, so in result to get following:
TARGETS= ftp_auto_backup sftp_auto_backup
Screenshot of dirs tree here.
I want use implicit rule for compiling, smth like this:
%.o: %.cpp
$(CXX) -c $(CXXFLAGS) $< -o $(O_DIR)/$#
But how can I specify separate O_DIR for each target int $(TARGETS) and for each build configuration? My main problem is in this step. I can paste all the makefile that I have at this moment, but it still won't build anything. Just in case here it is: http://pastebin.com/jjB5Ld1s
Thanks in advance, guys!
There are many ways to do this. The simplest seems to be by means of recursive Make. (I am not among those who think that this is always a bad idea.)
.PHONY: release
release: VERSION=Release
.PHONY: debug
debug: VERSION=Debug
release debug:
#$(MAKE) -S ftp_auto_backup sftp_auto_backup VERSION=$(VERSION)
Now to make the executables, given VERSION. We could handle the two project types with another layer of recursion, but we can do without it (and I won't go into detail about preprocessor macros and compiler/linker flags, since you seem to know about them already-- I'll spell them out if you like):
OBJ_LIST = foo.o bar.o baz.o
ftp_auto_backup: PROJECT_TYPE=FTP
ftp_auto_backup: $(addprefix $(VERSION)/ftp_auto_backup/obj/, $(OBJ_LIST))
sftp_auto_backup: PROJECT_TYPE=SFTP
sftp_auto_backup: $(addprefix $(VERSION)/sftp_auto_backup/obj/, $(OBJ_LIST))
ftp_auto_backup sftp_auto_backup:
#g++ -Wall $^ -o $# with various flags
$(VERSION)/ftp_auto_backup/obj/%.o: %.cc
#g++ -Wall -c $< -o $# with various flags
$(VERSION)/sftp_auto_backup/obj/%.o: %.cc
#g++ -Wall -c $< -o $# with various flags
Related
I am trying to write a makefile, suppose I have 4 source files in a directory src/app/:
src/app/file1.cpp
src/app/file2.cpp
src/app/file3.cpp
src/app/file4.cpp
and I want to create different object files (i.e. file1.o, file2.o etc.) into another directory called obj/. In the makefile, I am defining the variables like this:
$(SRC) := $(wildcard src/app/*.cpp)
$(OBJ) := $(addprefix obj/,$(notdir $(SRC:.cpp=.o)))
and my commands are like this:
all: $(OBJ)
$(OBJ): $(SRC)
$(CC) $(CFLAGS) -I/src/app/app.h -c $< -o $#
so when I run make, I see these operations:
g++ -g -Wall -I/src/app/app.h -c src/app/file1.cpp -o obj/file1.o
g++ -g -Wall -I/src/app/app.h -c src/app/file1.cpp -o obj/file2.o
g++ -g -Wall -I/src/app/app.h -c src/app/file1.cpp -o obj/file3.o
g++ -g -Wall -I/src/app/app.h -c src/app/file1.cpp -o obj/file4.o
You can see, the object files have different names but the source file is the same. How do I fix it ?
Please note that I can't use %.o: %.cpp since I have other targets in my makefile for different purposes.
If you can't use
obj/%.o: src/app/%.cpp
then the second simplest way is to add $(OBJ): to the front:
$(OBJ): obj/%.o: src/app/%.cpp
It's called "static pattern rules" - look it up in the GNU Make manual.
I have found a way to solve this (thanks to Zereges for the idea):
$(RGAOBJ): $(RGASRC)
$(CC) $(CFLAGS) -I/src/app/app.h -c \
$(addprefix src/app/,$(notdir $(#:.o=.cpp))) -o $#
I think there is a better way to do.
So any other pointer will be helpful.
The $< variable picks up the first dependency. It is used with generic targets which have variable targets and produce different results. The compile target would match a pattern as target and have a generic dependency. The first target doesn't change in your case.
Your constraint of not being able to use a generic rule is entirely defeating the purpose of the $< variable. A somewhat naive work-around is to translate the destination name back into the source, e.g.,
$(OBJ): $(SRC)
$(CC) $(CFLAGS) -I/src/app/app.h -c $(#:%.o=%.cpp) -o $#
The problem with that approach is that no all object files depend on all source files. As a result, every time one of the source files is changed all object files are produced. For tiny projects and source that may be viable. On anything which I'd consider a real project neither of these conditions holds.
My understanding on your statement on not being able to use pattern rules is that you already have rules for the same pattern but you need to build some targets with some special rules. A work around for that situation is to build targets with a custom suffix which actually build something different and just use a marker file to prevent unnecessary rebuilds. For example:
all: $(OBJ:%=%.custom)
%.o.custom: %.cpp
$(CC) $(CFLAGS) -W -I/src/app/app.h -c $< -o $(#:%.custom=%) && touch $#
My Makefile looks as follows:
CXX = g++
CXXFLAGS = -g
INCLUDES = -Iinclude/
OBJS = a1.o \
b1.o
LIBPATH= /usr/lib/<arch>
test-app:$(OBJS)
$(CXX) -o $# $(OBJS)
%.o : %.cpp
$(CXX) $(INCLUDES) -c $(CXXFLAGS) $< -o $#
I want to link two files lib1.so and lib2.so present in LIBPATH? Can anyone please help me with the syntax?
The syntax is
test-app:$(OBJS)
$(CXX) -o $# $(OBJS) -Lpath_to_your_lib -lyour_libname
Also you should use pkg-config to find those variables value.
Try this one:
LIBRARIES= -llib1 -llib2
...
test-app:$(OBJS)
$(CXX) -o $# -L$(LIBPATH) $(LIBRARIES) $(OBJS)
Consider that the arguments order are most of times important since the gcc compiler/linker process the files just one time in the given order and if the order was wrong errors like "Symbol not find" and "undefined reference" will be produced.
Though, I strongly recommend CMake since it's syntax is so easier, more dynamic and It supports many build platforms (IDEs, Compilers, Makefiles, etc.)
Update:
This configuration is likely more effective than the above:
SHARED_LIBRARIES= -L/path/to/shared_libs -llib1 -llib2
STATIC_LIBRARIES= -L/path/to/static_libs -llib1 -llib2 -L/another/path/to/static_libs -llib3
...
test-app:$(OBJS)
$(CXX) -o $# $(STATIC_LIBRARIES) $(SHARED_LIBRARIES) $(OBJS)
I've been building a C++11 library, and the number of header/source files has grown to the point where compiling programs invoking it, entails passing 20+ .cpp files to g++. I've been reading up on shared libraries and it seems to be the best solution.
However, as headers/source change frequently, I'm hoping to create a makefile that would automatically generate all the .so files from the headers and source.
To better demonstrate what I'm trying to do, I'll take one of my sub-libraries, Chrono and show how I would do this manually.
I first create the object files like so,
$ g++ -std=c++11 -fPIC -g -c -Wall ../src/Chrono/cpp/DateTime.cpp
$ g++ -std=c++11 -fPIC -g -c -Wall ../src/Chrono/cpp/Schedule.cpp
$ g++ -std=c++11 -fPIC -g -c -Wall ../src/Chrono/cpp/Duration.cpp
$ g++ -std=c++11 -fPIC -g -c -Wall ../src/Chrono/cpp/DayCount.cpp
So that I now have DateTime.o, Schedule.o, Duration.o, and DayCount.o in the current directory. I then create the .so file,
$ g++ -shared -Wl,-soname,libChrono.so.1 -o libChrono.so.1.0.1 DateTime.o Schedule.o Duration.o DayCount.o -lc
I then go,
$ rm ./*.o && ldconfig -n ./
So that my working directory now contains, libChrono.so.1.0.1 and the symlink libChrono.so.1.
There are quite a few subdirectories I need to do this for, so you can see that this quickly grows inefficient whenever changes to headers/source are made. I would be grateful if anyone can help me design a makefile that accomplishes all this simply by invoking make.
Thanks!
UPDATE:
Based on goldilock's advice and some digging, I managed to bang together:
CXX=g++
CFLAGS=-std=c++11
TARGET=./lib/libChrono.so.1.0.1
CHRONODIR=./src/Chrono
CHRONOSRC=$(wildcard $(CHRONODIR)/cpp/*.cpp)
CHRONOOBJ=$(join $(addsuffix ../obj/, $(dir $(CHRONOSRC))), $(notdir (CHRONOSRC:.cpp=.o)))
all: $(TARGET)
#true
clean:
#-rm -f $(TARGET) $(CHRONOOBJ)
./lib/libChrono.so.1.0.1: $(CHRONOOBJ)
#echo "======================="
#echo "Creating library file $#"
#echo "======================="
#$(CXX) -shared -Wl,-soname,$(join $(basename $#), .1) -o $# $^ -l
#echo "-- $# file created --"
$(CHRONODIR)/cpp/../obj/%.o : $(CHRONOSRC)
#mkdir -p $(dir $#)
#echo "============="
#echo "Compiling $<"
#$(CXX) $(CFLAGS) -fPIC -g -Wall -c $< -o $#
4 .o files are produced in lib/ but I get multiple definition complaints from ld. Before I was compiling the object files separately, but this unwinds CHRONOOBJ on one line. Any ideas?
Fortunately you included the origin of your problem:
I've been building a C++11 library, and the number of header/source files has grown to the point where compiling programs invoking it, entails passing 20+ .cpp files to g++.
Because this reveals a potential XY problem. The straightforward solution to this is to put object files into an archive (aka. a static library) and use that.
GNU make has an implicit rule for creating C++ .o files. It amounts to this:
%.o: %.cpp
$(CXX) $(CPPFLAGS) $(CXXFLAGS) -c $<
Meaning, if you make DateTime.o in a directory with a makefile that doesn't redefine this, it will make DateTime.o. You may want to add things to $(CXXFLAGS) however, e.g.:
CXXFLAGS += -Wall -Wextra --std=c++11
If you intend to stick with the shared lib route, -fPIC can go there too. That one line could be your entire makefile.
However, you also want to put these together, so you must first declare all the objects and a rule for combining them:
OBJS = DateTime.o Schedule.o Duration.o
libChrono.a: $(OBJS)
ar crvs $# $^
This last line (see man ar) creates the archive (libChrono.a) containing all the objects in $(OBJS). You can then use this with whatever program by placing it in the same directory (or a directory in the library path) and linking -lChrono. Only the necessary parts will be extracted and compiled in. This saves you having to maintain a shared lib in a system directory.
If you still think you need a shared lib, $# and $^ are automatic variables; you can use similar methodology to create a .so, something along the lines of:
SO_FLAGS = -shared
libChrono.so.1.0.1: $(OBJS)
$(CXX) $(SO_FLAGS) -Wl,-soname,libChrono.so.1 -o $# $^ -lc
If that is your first rule, make will take care of everything: building first the objects and then the library. Notice this one has excluded your normal $(CXXFLAGS) to duplicate exactly the compiler line from the question.
I work in a computational biophysics lab. I am not a programmer, although I do get paid to act like one. Here's my problem: the main product of the lab is a ginormous (50+ source files) C program. I need to get our lab's program to work with another lab's toolkit, which just so happens to be in the form of a series of C++ libraries (.a files). I can get the main library for our program to compile using the following makefile:
CC = gcc
#CC = icc
CFLAGS = -g -Wall
#CFLAGS = -xT -openmp -I/opt/local/include -I/usr/local/include -I/opt/GDBM/include
#CFLAGS = -O3 -g -Wall -I/opt/GDBM/include -fopenmp
LIB = mcce.a
AR = ar
ARFLAGS = rvs
SRC = all.c ddvv.c geom_3v_onto_3v.c ins_res.c strip.c\
app.c del_conf.c geom_apply.c line_2v.c vdotv.c\
avv.c del_prot.c geom_inverse.c load_all_param.c vector_normalize.c\
avvvv.c del_res.c geom_move.c load_param.c vector_vminusv.c\
cpy_conf.c det3.c geom_reset.c mxm4.c vector_vplusv.c\
cpy_prot.c det4.c geom_roll.c new_prot.c vector_vxv.c\
cpy_res.c dll.c get_files.c param_get.c param_exist.c\
db_close.c dvv.c iatom.c param_sav.c\
db_open.c free_strings.c ins_conf.c plane_3v.c pdbline2atom.c\
premcce.c init.c load_pdb.c write_pdb.c rotamers.c assign_rad.c get_connect12.c\
surfw.c vdw.c vdw_conf.c shuffle_n.c cmp_conf.c sort_conf.c sort_res.c id_conf.c\
energies.c assign_crg.c coulomb.c coulomb_conf.c\
get_vdw0.c get_vdw1.c relax_water.c relax_h.c monte.c monte2.c ran2.c\
relaxation.c collect_connect.c torsion.c vdw_fast.c hbond_extra.c swap.c quick_e.c\
check_tpl.c zip.c del_dir.c make_matrices.c\
mem_position.c probe.c add_membrane.c load_pdb_no_param.c ga_engine.c rotamers_ga.c compute_patches.c
OBJ = $(SRC:.c=.o)
HEADER = mcce.h
$(LIB): $(OBJ)
$(AR) $(ARFLAGS) $(LIB) $(OBJ)
$(OBJ): $(HEADER)
.c.o:
$(CC) $(CFLAGS) -c $*.c
clean:
rm -f *.o mcce.a
The executable itself then compiles with this makefile:
CC = gcc -g -O3
#CC = icc -xT -static-intel -L/opt/local/lib -L/usr/local/lib
mcce: mcce.c lib/mcce.h lib/mcce.a
# $(CC) -o mcce mcce.c mcce.a /opt/GDBM/lib/libgdbm.a -lm -lz -openmp; cp mcce bin
$(CC) -o mcce mcce.c lib/mcce.a -lgdbm -lm -lz -fopenmp; cp mcce bin
I can get a standalone version of the other lab's code to compile using this other makefile:
OEDIR = ../..
INCDIR = $(OEDIR)/include
LIBDIR = $(OEDIR)/lib
INCS = -I$(INCDIR)
LIBS = -L$(LIBDIR) \
-loezap \
-loegrid \
-loefizzchem \
-loechem \
-loesystem \
-loeplatform \
-lz \
-lpthread -lm
CXX = /usr/bin/c++
RM = rm -f
CXXFLAGS = -m64 -W -Wall -O3 -fomit-frame-pointer -ffast-math
LFLAGS = -m64 -s
TEXT2HEX = ../text2hex
PROGRAMS = other_labs_code
.SUFFIXES: .cpp
.SUFFIXES: .o
.cpp.o:
$(CXX) $(CXXFLAGS) $(INCS) -c $<
.SUFFIXES: .txt
.SUFFIXES: .itf
.txt.itf:
$(TEXT2HEX) $< InterfaceData > $#
all: $(PROGRAMS)
clean:
$(RM) $(PROGRAMS)
$(RM) ii_files core a.out *.itf
$(RM) *.o
other_labs_code.o: other_labs_code.cpp other_labs_code.itf
other_labs_code: other_labs_code.o
$(CXX) other_labs_code.o $(LFLAGS) -o $# $(LIBS)
I know that I have to change the paths of the various libs and stuff, but other than that, how do I combine all of these makefiles into one working product? Also, since some of the source files that go into compiling my program's main library (mcce.a) are going to need to be able to call functions from the C++ source file, it's the library's makefile that I need to modify, right?
I know extremely little about makefiles, so even if someone can just point me in the direction of a tutorial that covers this kind of problem (writing a makefile for a many source file C and C++ program), that may be sufficient.
For bonus points, the C++ FAQ says that:
You must use your C++ compiler when compiling main() (e.g., for static initialization)
Your C++ compiler should direct the linking process (e.g., so it can get its special libraries)
I don't exactly know what those things are supposed to mean, but assuming that I did, are there any other important points like that I should be aware about when combining C and C++?
Preparing the code
C programs cannot just use C++ symbols. Unless the authors of the C++ code arranged for that. This is because some features that C++ offers, such as function overloading (having several functions of the same name but with different formal arguments) demand that the function name be mangled in some way. Else the linker would see the same symbol defined several times. C compilers don't understand this name mangling and therefore cannot use C++ symbols. There are, generally, two possible solutions.
Declare and define all C++ symbols that the C code wants to use within extern "C" { ... } blocks and let your C++ tools handle the linking. The C code does not need to be changed in this case.
Compile the C code with the (exact same) C++ compiler as the C++ code. Fix the C++ compiler's complaints of the C code as they arise. Depending on project size and coding style, this may or may not be a lot of work.
Preparing a master Makefile
I personally try to avoid becoming intimate with other people's Makefiles, especially if they are subject to change or complex. So, assuming generating a Makefile that orchestrates the bits you already have (as opposed to writing one Makefile incorporating everything) is okay, I'd start out with something similar to this:
I'm assuming that
One of the above-mentioned options has been implemented
The code for mcce.a lies in subdirectory mcce/lib/
other_labs_code.cpp lies in other_labs_code/
The main function you want to use lies in ./mystuff.c
the following top-level Makefile may get you started
CXX = c++
CXXFLAGS = -m64 # From other_labs_code/Makefile
LDFLAGS = -m64 -L<path to OEDIR> # From other_labs_code/Makefile
LIBS = -lgdbm -lm -lz # From mcce/lib/Makefile
LIBS += -loezap \ # From other_labs_code/Makefile
-loegrid \
-loefizzchem \
-loechem \
-loesystem \
-loeplatform \
-lpthread
mystuff: mystuff.c mcce/lib/mcce.a other_labs_code/other_labs_code.o
$(CXX) $(CPPFLAGS) $(CXXFLAGS) $(LDFLAGS) -o $# $^ $(LIBS)
mcce/lib/mcce.a:
cd mcce/lib/ && $(MAKE) CC="$(CXX) -m64" mcce.a
other_labs_code/other_labs_code.o:
cd other_labs_code/ && $(MAKE) other_labs_code.o
Makefile: mcce/lib/Makefile other_labs_code/Makefile
echo "Warning: `pwd`/$# is out of date" >&2
This Makefile will employ the existing sub-project Makefiles to do the compilations. If the sub-project Makefiles have a newer timestamp than this Makefile, potentially rendering it obsolete, then this will be warned about. The linking basically works by combining the required libraries of both sub-projects. I've removed duplicates. The compiler switches are basially those of the original authors since compiling is delegated to the sub-projects. The code both sub-projects generate must be for the same platform. If your compiler is gcc/g++ then either -m64 is the default and therefore redundant in the second project or should be added to the first project. I have illustrated injecting it into the first project without changing their Makefile (using GNU make). NB: This example also causes the first project to be compiled with the C++ compiler.
An extern "C" {...} block located in a C or C++ header file that C code wants to include should look like this
/* inclusion guard etc */
#if defined(__cplusplus)
extern "C" {
#endif
/* C declarations */
#if defined(__cplusplus)
}
#endif
/* inclusion guard etc */
Minor points
In the first posted Makefile, I suggest changing the bottom part to
.c.o:
$(CC) $(CFLAGS) -c -o $# $<
clean:
rm -f $(OBJ) mcce.a
.PHONY: clean
which is a tiny bit cleaner.
The second Makefile is broken. The bottom rule links the binary and then copies it to a directory named bin, if it exists, else a copy of the file is created and named `bin'. If the linking fails, that fact is not propagated to the caller, i.e. the error is ignored. The bottom rule should read
mcce: mcce.c lib/mcce.h lib/mcce.a
$(CC) -o $# mcce.c lib/mcce.a -lgdbm -lm -lz -fopenmp
cp mcce bin/
i.e. the link command should be on its own line and that `bin' is supposed to be a directory should be made explicit.
http://www.gnu.org/software/make/manual/make.html#Introduction
This is my current makefile.
CXX = g++
CXXFLAGS = -Wall -O3
LDFLAGS =
TARGET = testcpp
SRCS = main.cpp object.cpp foo.cpp
OBJS = $(SRCS:.cpp=.o)
DEPS = $(SRCS:.cpp=.d)
.PHONY: clean all
all: $(TARGET)
$(TARGET): $(OBJS)
$(CXX) $(CXXFLAGS) $(LDFLAGS) $(OBJS) -o $(TARGET)
.cpp.o:
$(CXX) $(CXXFLAGS) -c $< -o $#
%.d: %.cpp
$(CXX) -M $(CXXFLAGS) $< > $#
clean:
rm -f $(OBJS) $(DEPS) $(TARGET)
-include $(DEPS)
It works perfectly with one exception. If the directory is already clean (no *.d, *.o) and I run 'make clean', it re-creates the dependencies, then immediately deletes them:
[user#server proj]$ make
g++ -M -Wall -O3 foo.cpp > foo.d
g++ -M -Wall -O3 object.cpp > object.d
g++ -M -Wall -O3 main.cpp > main.d
g++ -Wall -O3 -c main.cpp -o main.o
g++ -Wall -O3 -c object.cpp -o object.o
g++ -Wall -O3 -c foo.cpp -o foo.o
g++ -Wall -O3 main.o object.o foo.o -o testcpp
[user#server proj]$ make clean
rm -f main.o object.o foo.o main.d object.d foo.d testcpp
[user#server proj]$ make clean
g++ -M -Wall -O3 foo.cpp > foo.d
g++ -M -Wall -O3 object.cpp > object.d
g++ -M -Wall -O3 main.cpp > main.d
rm -f main.o object.o foo.o main.d object.d foo.d testcpp
[user#server proj]$
I don't understand why the second 'make clean' would re-generate the dependency files. How can I avoid this? This isn't a big deal for this contrived example, but for a large project, it can be quite time-consuming.
Thanks.
It's because the .d files are being -included unconditionally. As far as make knows, they could add dependencies or commands to the clean target. All included files are built first for this reason, otherwise you might get an incorrect or failed build. To disable this, you want to conditionally include the dependency files:
ifneq ($(MAKECMDGOALS),clean)
-include $(DEPS)
endif
An alternative solution is to generate the dependency files using touch and have them replaced by actual data as a side-effect of compilation. This is how automake does its dependency tracking, as it makes one-time builds faster. Look into the -MD and -MMD options to gcc if you want to go this route. Use a pattern rule like:
%.d:
#touch $#
To initially create the dependency files.
If you want to skip the include for multiple targets, you can use the filter function.
MAKEFILE_TARGETS_WITHOUT_INCLUDE := clean distclean doc
# Include only if the goal needs it
ifeq ($(filter $(MAKECMDGOALS),$(MAKEFILE_TARGETS_WITHOUT_INCLUDE)),)
-include $(DEPS)
endif
It wants to regenerate the dependency files because it always tries to regenerate all of the makefiles, including -include'd makefiles, before doing anything else. (Well, actually, for me it doesn't do that - I have GNU Make 3.81 - so maybe it's a bug in your version that was fixed, or an optimization that mine has and yours doesn't. But anyway.)
The easiest way around this is to write your rules so they generate the .d files as a side effect of regular compilation, rather than giving explicit rules to generate them. That way, when they're not there, Make doesn't know how to generate them so it doesn't try (in a clean tree, the .cpp.o rules are enough, you don't need the header file dependencies). Look at an Automake-generated makefile -- a simple one -- to see how it's done.
The leading - in -include means that make won't complain if the dependencies are missing and can't be remade, but it doesn't mean it won't try to make them first (and, in this case, succeed) -- after all, anything interesting or important could be in the included files, whence the let's-try-making them attempt. I don't think there's a way to stop that.
For docs on include and -include, see here.