I am writing a gnu make file to build and run C++ unit tests. I have the makefile put its .o files in the same directory that holds the make file.
We have a different set of makefiles used to build our products for delivery. Those makefiles puts each .o file in the same directory that has the corresponding C++ source file.
My unit test makefile defines its .o target as "%.o: %.cpp". In that makefile, I define VPATH to have the location of the .cpp files. In addition, my unit test compilation command generates and uses .d files using the g++ MMD and MP options.
So here is the problem I am having.
I want my unit test makefile target to only evaluate the .o target by looking in my unit test makefile directory.
If the product delivery makefile already generated a .o out where the source file lives, I still want my unit test makefile to only consider its directory to determine if I need to rebuild the .o file.
However, that's not happening. If a product delivery makefile had already put a .o where the source code lives, the unit test makefile sees that .o, and it says that the .o does not need to be built.
Is there a way for me to force my unit test makefile to only consider the unit test make file directory when evaluating .o file targets?
Are you saying that the .o file is found via your VPATH setting?
You can use pattern-specific vpath to restrict the lookup to specific types of files:
vpath %.cpp $(SRCDIR)
instead of setting the global VPATH
Related
I want my QtCreator project to have a Makefile with a "make clean" rule that deletes the executable.
Normally, when making a Makefile for a simple C++ project, I would put this rule in the Makefile, where neatprogram is the executable (on Linux):
clean:
rm -f neatprogram
But QtCreator uses qmake to generate a Makefiles for me. By default, it even adds a clean rule to the Makefile! But it only removes object files and such. How can I make it so the Makefile generated by qmake also removes (deletes) the single executable file for my program?
There's a predefined target distclean which removes all generated files including an executable. But note that Makefile itself will also be removed.
Alternatively, you can define your own target like this:
myproject.pro
QMAKE_EXTRA_TARGETS += myclean
#myclean.target = myclean
myclean.depends = clean
myclean.commands = -$(DEL_FILE) $(DESTDIR_TARGET)
I have the following project structure:
/
general.pro
a/
a.pro
some files
b/
b.pro
some files
c/
Makefile
some files
general.pro is a TEMPLATE=subdirs style qmake-project. The two other project files are normal/common qmake project files (folder a and b). The third folder (folder c) contains a kernel module with the following Makefile: http://pastebin.com/Bv39D6KK
I'm wondering if that Makefile can be translated somehow to a qmake project file.
If not, is there a way to the the general.pro project file that there is a "c" folder containing a Makefile which should be ran too?
Regards
I really doubt, you can include Makefile in a .pro file.
Here is my thoughts about what you can do:
If c is your project, you could simply create one more .pro file for it.
If it is not, and you don't need to edit it, you could build it without including into subdirs (if it's a library, you are using in a or b, you still can build it, and then create a .pri file and add includes and libs etc).
If you need it for a build machine or for deploying, you could use build script.
You could use cmake.
Update:
It turns out, there is a solution.
Though, I could not make it work myself, I hope it helps. What you need is to add following lines to a top-level pro file:
mytarget.commands = make -C c
QMAKE_EXTRA_TARGETS += mytarget
PRE_TARGETDEPS += mytarget
Where c is a name of sub-directory, containing Makefile.
I want to copy a data file from a directory in my source tree to the directory of the linked app so it's available at runtime, on Windows only. There appear to be two suggested techniques: use a post target dependency to issue a DOS copy command (Including resource files in Qt Creator build directory) or use an install step (Copy a file to the build directory after compiling project with Qt), but I cannot make either work in the way I would like.
The former requires me to use qmake path variables to generate my source and destination paths, but they contain backslash path separators, which the DOS copy command cannot handle.
The install solution forces other users of my project to set up a post build step in Qt Creator before it will work (one per configuration, in fact) and I would like to avoid this, as I want to make my project work with a default Qt Creator installation.
Is there any way to do this apparently simple task that can be wholly defined in the .pro file for the project? For example, is there a way to expand qmake path variables in a platform specific way?
Though these commands run ONLY after the executable is ACTUALLY linked, this solution doesn't require an external batch file. Note: this a Windows-only solution:
From our .pri file:
win32 {
...
# Copy the appropriate dll files into the target destination directory.
QMAKE_TBB_LIBDIR = $$quote($$PWD/MySource/MyLibs/$${PLATFORM_NAME}/vc9)
QMAKE_POST_LINK = copy /y $${replace(QMAKE_TBB_LIBDIR, /, \\)}\\*.dll > $${replace($$quote(DESTDIR), /, \\)}
...
}
This places a command in the Makefile that copies all the .dll files in MyLibs/x64 or MyLibs/Win32 into the destination directory.
However, if the executable did not need to be linked, then the .dlls are NOT copied.
The post build batch file would not have this limitation.
I'm currently transferring a project built with qmake to CMake.
In the version with qmake, in the .pri file, there was
MOC_DIR = .moc/$${PLATFORM_NAME}
that permitted to produce the MOC temporary files in a given directory, keeping the sources clean. How to do the same thing with CMake?
Note: with CMake, I use the FindQt4.cmake package and the command QT4_WRAP_CPP().
As baysmith says, if your goal is to keep your source directory clean, the real solution is to use CMake's "out-of-source" builds feature. If you're on Windows, set "Where to build the binaries" to a new directory, different from the "Where is the source code" directory. If you're on Unix, it goes something like this:
cd <source directory>
mkdir build
cd build
cmake ..
make
By running CMake on a different directory, all of the build files will go into that directory, and your sources will stay clean. (Note: the build directory doesn't have to be inside the source directory. See the CMake wiki for more details.)
If "out-of-source" doesn't work for you, I was able to find one other option. Based on what I can tell from the Qt4Macros.cmake file installed with my CMake 2.8, it isn't accessible as a config parameter. Here's the relevant line:
SET(_moc ${CMAKE_CURRENT_BINARY_DIR}/${_current_MOC})
The workaround is to change all of your MOC include directives to specify the subfolder you'd like to build to.
#include "moc/mainwindow.moc"
After creating the moc directory inside my build directory, there were no problems building, and my MOC file was in the new directory.
I'm using a Makefile to build an embedded project. I've inherited the project from numerous previous developers who haven't been using Make to its full potential, and I'd like to be able to specify the project version in the makefile using defines on the build command. However, there's already a build rule that builds all the object (.o) files. Is there any way to override that build rule for a specific object file so that I can add -D flags to the compiler ?
Another reason I'd like to be able to specify the project version in the makefile is so that I can have it generate artifacts with the build version in the names of the resulting files produced by the build process.
Yes, you can override a pattern rule (which is what I bet your .o rule is), just by having a specific rule (and the order of the rules doesn't matter):
%.o:
do_generic_things
x.o:
do_specific_things -Dproject_version
Yes, you can put a build version in a file name. There's more than one way to do it-- the best is probably to put it in the target name:
%$(B_VERSION).o: %.c
$(CC) -c -DBUILD_VERSION=$(B_VERSION) -Whatever $< -o $#
If you are using GNU make and you only want to change compiler options, you can use target-specific variables, like so:
x.o: CFLAGS += -DEXTRA_SYMBOL_FOR_X
This also works recursively, i.e. the target-specific value for x.o also is in effect for all targets which x.o depends on, meaning that if you build multiple executables in your makefile, you can set a target-specific variable on the executable itself, which will be in effect for all the object files:
foo: CFLAGS += -DEXTRA_SYMBOL_FOR_FOO_APP