Is there an automated way to remove unnecessary targets from Makefile?
I used ones generated by qmake, but I am to run them on machine doesn't have QT. Since the Makefile generated by qmake, it contains QT-related targets such as 1) "Makefile:" that call "$(QMAKE)" 2) "qmake:" ; as well as QT files in dependencies, such as "/usr/share/qt4/mkspecs/common/g++.conf" and so on.
Makefile: my_project.pro /usr/share/qt4/mkspecs/linux-g++/qmake.conf /usr/share/qt4/mkspecs/common/g++.conf \
/usr/share/qt4/mkspecs/common/unix.conf \
...
$(QMAKE) -spec /usr/share/qt4/mkspecs/linux-g++ -unix CONFIG+=debug -o Makefile my_project.pro
...
qmake: FORCE
#$(QMAKE) -spec /usr/share/qt4/mkspecs/linux-g++ -unix CONFIG+=debug -o Makefile my_project.pro
I have tried to remove those targets by hand and than could successfully compile project with them. The question is if there a simple automated way?
No there isn't. If you are using qmake, it means that you want to use it on computers with qt installed. As far as i know you shouldn't share your sources with Makefile's but with .pro files only. Anyone compiling it for himself should call qmake before make (or 'nmake' if you are using visual).
If you are not using qt at all, and use only qmake to generate Makefile, then there are alternatives (although not as simple as qmake, I admit) such as cmake or autoconf/automake.
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)
For a university project we made an OpenGL application which uses Qt for the GUI. When I use qmake -spec macx-g++ project.pro I can make a Makefile, and if I then do make it correctly makes the application. However, when I then send the complete folder to the other person in the project and he does make he gets the error
Makefile:209: warning: overriding commands for target `moc_window.cpp'
Makefile:203: warning: ignoring old commands for target `moc_window.cpp'
make: *** No rule to make target `/usr/lib64/qt-3.3/mkspecs/default/qmake.conf', needed by `Makefile'. Stop.
However, when in the same folder he does qmake; make it does work correctly. The problem is that when handing the code in we don't know if the professor has qmake available, so we would like it to work by only using make. Are we missing something that should be addded to have the Makefile made with qmake work, without having to do qmake again? Our .pro file is below.
TEMPLATE = app
TARGET = smoke
QT = core gui opengl
greaterThan(QT_MAJOR_VERSION, 4): QT += widgets
SOURCES += \
fluids.cpp \
simulation.cpp \
visualization.cpp \
window.cpp \
myglwidget.cpp \
vector.cpp \
grid.cpp \
scalar.cpp
HEADERS += \
window.h \
myglwidget.h \
simulation.h \
vector.h \
grid.h \
visualization.h \
scalar.h
INCLUDEPATH += fftw-2.1.5/include /usr/local/include include
LIBS += -L"$$_PRO_FILE_PWD_/fftw-2.1.5/lib" -lrfftw -lfftw -framework OpenGL -framework GLUT -stdlib=libc++
QMAKE_CXXFLAGS += -stdlib=libc++
QMAKE_CXXFLAGS += -std=c++11
FORMS += \
window.ui
The build directory is not portable. It is only ever meant to work on the system where you executed qmake, and for the particular Qt install that you ran qmake from. Recall that each Qt install has its own qmake, so e.g. if you have three Qt versions, each provides its own qmake that you must use to build a project using that version.
The project you ship should contain the .pro file, the sources, and whatever else the build calls for, like icon files, resources, etc.
The recipient, to build it, should:
Create a build folder.
cd into the build folder.
qmake /path/to/sources/project.pro && make -j
That's how you distribute and build Qt projects.
why does qmake not build the application directly?
Why do you not make your own shoes? The reasons are the same. Don't reinvent the wheel.
Of course, engineers sometimes have an itch to scratch. Enter Qt Build System (qbs). If your project's build is given as a .qbs file, then you do:
Create a build root folder.
cd into the build root folder.
qbs -f /path/to/sources/project.qbs - this builds the project.
I am using a Qt .pro file using the SUBDIRS template (mainly following this answer).
Furthermore I am building my solution using qmake -recursive MyProject.pro and nmake Release.
Now I want to supply a separate batch file for cleaning up the release output and meta files (not the debug ones though).
The problem is that for the top-level Makefile, only clean and distclean is generated by qmake while for the subdirectories, there are also release-clean and debug-clean (also the folders contain an additional Makefile.Debug and Makefile.Release).
What I want to do is calling
nmake Makefile release-clean
from the batch script. However the top-level makefile does not contain this configuration.
Now I could call the equal line for every subproject manually but this is obviously my least favoured option.
Is there a way to either get qmake to generate a release-clean target for the top-level makefile or is there another way to simply clean release files?
PS: I'm using nmake, so yes I'm on Windows (XP) and using MSVC (2008)
The following batch script does the job :
REM set up environment
SET VISUALDIR=C:\PROGRA~1\MICROS~1.0
PUSHD %VISUALDIR%\VC
CALL vcvarsall.bat x86
POPD
REM clean solution
msbuild yoursolution.sln /p:Configuration=Release /t:clean
REM and you may want to add a build command :
msbuild yoursolution.sln /p:Configuration=Release
Ever tried nmake Makefile.Release clean, that should do the job.
In my project I have made configure.ac and Makefile.am files correctly so my components compile and dynamically link to the appropriate libraries. One of these components links to a library that uses QT, so the appropriate Makefile must be generated out of the .pro file prior compilation on the target system.
For this I think that I need to find a way to tell my make scripts, through Makefile.am perhaps, that this library must be compiled on its own by first running qmake and the generated Makefile in that directory.
Is this even possible? If so, how do I do it?
Researching on my own I have found an apparently abandoned project called “AutoTroll” which is supposed to automatically alter files of autotools in order to add compatibility with Qt4. I have tried to make it work with no luck. It lacks a proper documentation also.
Without this tool, compiling Qt4 modules with autotools requires a lot of hacking and interventions, making it really hard and even more for a cross-platform application.
I have switched to CMake. CMake’s setup is far easier than autotools’ and it supports Qt4 modules out of the box.
We do this, its not that difficult. In configure.ac:
QT_QMAKE
[
echo $QMAKE -o Makefile.myapp $(realpath $(dirname $0))/myapp.pro
$QMAKE -o Makefile.myapp $(realpath $(dirname $0))/myapp.pro
]
Then (Assuming your macros are located in the standard m4 directory), make a file called qt_qmake.m4 there.
AC_DEFUN([OTT_QT_QMAKE],[
if test -z "$QMAKE"; then
QMAKE=$(which qmake)
$QMAKE -v > /dev/null 2>&1
if test $? -ne 0; then
AC_MSG_ERROR([qmake executable not found!])
fi
fi
AC_SUBST(QMAKE)
])
Then in Makefile.am:
ACLOCAL_AMFLAGS=-Im4
all-am:
make -f Makefile.myapp all
install-am:
make -f Makefile.myapp install
qmake_all:
make -f Makefile.myapp qmake_all
clean-am:
make -f Makefile.myapp clean
That should align with the targets that QTCreator uses, and allows you to "bootstrap" qmake using autotools to make a config.h for instance, or global qmake include file to make shadow builds easier. Theres a lot I'm leaving out if you want to have version checking,etc... but it should get you started. If you built qt yourself, or have it not in your path, ie redhat (/usr/lib{64}/qt5/bin/qmake), you can just use the QMAKE variable to point to it. QT is smart enough with that to take it from there usually. I know its not the most elegant solution, but its worked for us cross-linux for almost a decade.
I am using cmake to build my project. For UNIX, I would like to type make from my project's root directory, and have cmake invoked to create the proper Makefiles (if they don't exist yet) and then build my project. I would like the cmake "internal" files (object files, cmake internal Makefiles, etc.) to be hidden (e.g. put in a .build directory) so it doesn't clutter my project directory.
My project has several sub-projects (in particular, a library, a user executable, and a unit test executable). I would like Makefiles (i.e. I type make and this happens) for each sub-project to execute cmake (as above) and build only that sub-project (with dependencies, so the library would be built from the executables' Makefiles, if needed). The resulting binary (.so library or executable) should be in the sub-project's directory.
I made a Makefile which does the main project bit somewhat well, though it feels somewhat hackish. I can't build specific targets using it, because my Makefile simply calls make in cmake's build directory.
Note that because the library is a sole dependency (and probably doesn't need to be build manually, and because I'm lazy) I omitted it in my Makefile.
BUILD_DIR := .build
.PHONY: all clean project-gui ${BUILD_DIR}/Makefile
all: project-gui project-test
clean:
#([ -d ${BUILD_DIR} ] && make -C ${BUILD_DIR} clean && rm -r ${BUILD_DIR}) || echo Nothing to clean
project-gui: ${BUILD_DIR}/Makefile
#make -C ${BUILD_DIR} project-gui
#cp ${BUILD_DIR}/project-gui/project-gui $#
project-test: ${BUILD_DIR}/Makefile
#make -C ${BUILD_DIR} project-test
#cp ${BUILD_DIR}/project-test/project-test $#
${BUILD_DIR}/Makefile:
#[ -d ${BUILD_DIR} ] || mkdir -p ${BUILD_DIR}
#[ -f ${BUILD_DIR}/Makefile ] || (cd ${BUILD_DIR} && cmake ${CMAKE_OPTS} ..)
If it helps, here's my project structure (if this is "wrong" please tell me -- I'm still learning cmake):
project/
project/CMakeLists.txt
project/common.cmake
project/Makefile -- see Makefile above for this; should be replaced with something better, building libproject, project-gui, and project-test
project/libproject/
project/libproject/CMakeLists.txt
project/libproject/libproject.so -- after build
project/libproject/Makefile -- doesn't exist yet; should build libproject only
project/libproject/source/
project/libproject/include/
project/project-gui/
project/project-gui/CMakeLists.txt
project/project-gui/Makefile -- doesn't exist yet; should build libproject then project-gui
project/project-gui/source/
project/project-gui/include/
project/project-test/
project/project-test/CMakeLists.txt
project/project-test/Makefile -- doesn't exist yet; should build libproject then project-test
project/project-test/source/
project/project-test/include/
If you haven't caught on yet, I'm basically looking for a way to build the project and sub-projects as if cmake wasn't there: as if my project consisted of only Makefiles. Can this be done? Is the solution elegant, or messy? Should I be trying to do something else instead?
Thanks!
If cmake is generating the makefiles, you can simply include the generated makefile in the master makefile, eg
# makefile
all: # Default
include $GENERATED
$GENERATED:$CMAKEFILE
# Generate the makefile here`
The included files are generated then make is restarted with the new included files. The included files should detail the targets, etc.
You should be able to change the location of used files using the vpath directive, see e.g. the Gnu make manual,
vpath %.o project/.build
else the tedious way is to rewrite the rules making note of the necessary directory.
Ed:
Perhaps we shouldn't use a flat makefile.
Try something like:
# makefile
all: gui test
clean:
$(MAKE) -f $(GUI-MAKE) clean
$(MAKE) -f $(TEST-MAKE) clean
gui:$(GUI-MAKE)
$(MAKE) -f $(GUI-MAKE) all
$(GUI-MAKE):$(GUI-CMAKE)
# Generate
# Same for test
This should work if the $(MAKE) -f $(GUI-MAKE) all command works on the command line, and we've hidden cmake in the generating target. You would have to copy any other targets to the master makefile as well, and take care running make in parallel.
Propagating object files through should involve something like
%.o:$(GUI-MAKE)
$(MAKE) -f $(GUI-MAKE) $#
although you'll probably get errors trying to make test objects