Buildroot: qt application with an empty install target - qt

I am integrating my own Qt app into buildroot. *.mk file follows.
CATCHER_SITE=http://g7/gitlab/igorsk/catcher.git
CATCHER_SITE_METHOD=git
CATCHER_VERSION=master
CATCHER_DEPENDENCIES=qt
ifeq ($(BR2_PACKAGE_QT5),y)
CATCHER_QMAKE = $(QT5_QMAKE)
else
CATCHER_QMAKE = $(QT_QMAKE)
endif
define CATCHER_CONFIGURE_CMDS
(cd $(#D); $(TARGET_MAKE_ENV) $(CATCHER_QMAKE))
endef
define CATCHER_BUILD_CMDS
$(TARGET_MAKE_ENV) $(MAKE) -C $(#D)
endef
define CATCHER_INSTALL_TARGET_CMDS
$(TARGET_MAKE_ENV) $(MAKE) INSTALL_ROOT=$(TARGET_DIR) -C $(#D) install
endef
$(eval $(generic-package))
The app compiles, but it doesn't get installed to a target directory (and therefore to resulting rootfs ). During buildroot's "Installing to target" phase I get Nothing to be done for 'install'. message. buildroot/output/build/catcher-master/Makefile has emtpy install rule.
Buildroot 2015.08.1
Qt 4.8.7
The question is: why is this happening and how do I get my app installed to target?

Related

make - how to list googletest lib as dependency

I am able to build googletest and use it to run unit tests.
In MY makefile for my unit_test.cpp, I need to check whether googletest libs exist in ..\googletest\ and only if they do not exist, I want to run cmake and make for googletest.
Running cmake and make even if they are built takes 30 secs so I only want to run cmake and make if I actually have to.
QUESTION
In MY makefile for my unit_test.cpp, what could I list as a dependency so that building googletest only happens if actually necessary?
A "brute force" approach would be to list googletest\build\lib\libgtest.a but this would break if, however unlikely, googletest changes the output name from lib\ to libs\.
If you are worried about possible change of the file layout in the build directory, you can use cmake --install command and directly specify the subfolders for header files and libraries before running cmake configure step. CMAKE_INSTALL_PREFIX variable allows to specify install directory and CMAKE_INSTALL_INCLUDEDIR, CMAKE_INSTALL_LIBDIR variables allow to specify subfolders for header files and libraries, accordingly:
GOOGLETEST_SRC_DIR := googletest
GOOGLETEST_BUILD_CACHE_DIR := googletest_build_cache
GOOGLETEST_SDK_DIR := googletest_sdk
GOOGLETEST_SDK_INCLUDE_DIR := include
GOOGLETEST_SDK_LIB_DIR := lib
GOOGLETEST_LIB := gtest
GOOGLETEST_MAIN_LIB := $(GOOGLETEST_LIB)_main
UT := ut
UT_SRC := ut.cpp
default_target: $(UT)
$(GOOGLETEST_BUILD_CACHE_DIR) :
cmake \
-DCMAKE_INSTALL_PREFIX=$(shell pwd)/$(GOOGLETEST_SDK_DIR) \
-DCMAKE_INSTALL_LIBDIR=$(GOOGLETEST_SDK_LIB_DIR) \
-DCMAKE_INSTALL_INCLUDEDIR=$(GOOGLETEST_SDK_INCLUDE_DIR) \
-B $(GOOGLETEST_BUILD_CACHE_DIR) -S $(GOOGLETEST_SRC_DIR)
cmake --build $(GOOGLETEST_BUILD_CACHE_DIR) --parallel
touch $(GOOGLETEST_BUILD_CACHE_DIR)
$(GOOGLETEST_SDK_DIR): $(GOOGLETEST_BUILD_CACHE_DIR)
cmake --install $(GOOGLETEST_BUILD_CACHE_DIR)
touch $(GOOGLETEST_SDK_DIR)
$(UT): $(UT_SRC) $(GOOGLETEST_SDK_DIR)
g++ $(UT_SRC) -o $(UT) \
-I$(GOOGLETEST_SDK_DIR)/$(GOOGLETEST_SDK_INCLUDE_DIR) \
-L$(GOOGLETEST_SDK_DIR)/$(GOOGLETEST_SDK_LIB_DIR) \
-l$(GOOGLETEST_MAIN_LIB) -l$(GOOGLETEST_LIB)
clean:
rm -f $(UT)
rm -fR $(GOOGLETEST_BUILD_CACHE_DIR) $(GOOGLETEST_SDK_DIR)

How to make Makefile generated by qmake on windows? (nmake and mingw-make)

OS: Windows 10, x64
I have a simple demo of qt console project, which simply print hello world.
This project can be built and run correctly(with MSVC kit), but I want to separate the process.
First, I click "execute qmake" in the right-click menu on the project in Qt Creator, I got a make file in the release and debug directory
build-hello-Desktop_Qt_5_12_3_MSVC2017_64bit-Release\makefile
open cmd, cd to this directory, and then the story ends.
If I use nmake, I got error C1083, which tell me can not find stdio.h
If I use make on windows or mingw-make32, I still got an error missing separator.
I have 2 questions:
1.Can someone give a full instruction of how to make this makefile both with mingw-make32 and nmake?
2.The makefile generated by qmake looks very complex and illegible, not like those makefiles in tutorial. Is it just the same as a normal makefile, or it's special?
I search for a lot but still can get the clear solution so please help.
the Makefile looks like this:
#############################################################################
# Makefile for building: hello
# Generated by qmake (3.1) (Qt 5.12.3)
# Project: ..\name\hello.pro
# Template: app
# Command: C:\Qt\Qt5.12.3\5.12.3\msvc2017_64\bin\qmake.exe -o Makefile ..\name\hello.pro -spec win32-msvc "CONFIG+=qtquickcompiler"
#############################################################################
MAKEFILE = Makefile
EQ = =
first: release
install: release-install
uninstall: release-uninstall
QMAKE = C:\Qt\Qt5.12.3\5.12.3\msvc2017_64\bin\qmake.exe
DEL_FILE = del
CHK_DIR_EXISTS= if not exist
MKDIR = mkdir
COPY = copy /y
COPY_FILE = copy /y
COPY_DIR = xcopy /s /q /y /i
INSTALL_FILE = copy /y
INSTALL_PROGRAM = copy /y
INSTALL_DIR = xcopy /s /q /y /i
QINSTALL = C:\Qt\Qt5.12.3\5.12.3\msvc2017_64\bin\qmake.exe -install qinstall
QINSTALL_PROGRAM = C:\Qt\Qt5.12.3\5.12.3\msvc2017_64\bin\qmake.exe -install qinstall -exe
DEL_FILE = del
SYMLINK = $(QMAKE) -install ln -f -s
DEL_DIR = rmdir
MOVE = move
SUBTARGETS = \
release \
debug
full instruction of how to make this makefile with nmake
run visual studio command prompt and then run nmake inside it rather than run nmake in common cmd, because vs command prompt has already set the specific environment variables such as the path of includes and c++ standard library, whichout which cl.exe and link.exe can not work.
This is the reason exacly why can not find stdio.h.

How to create a Qt Creator project (.pro) file equivalent to existing Makefile

There is a project which is build via make command, where the Makefile is provided. Following are the Makefile contents:
TARGETT=gnulinux
OROPATH=/usr/local
CXXFLAGS=-I${OROPATH}/include -DOROCOS_TARGET=${TARGETT} -Wall
LDFLAGS=-L${OROPATH}/lib -Wl,-rpath ${OROPATH}/lib -lorocos-taskbrowser-${TARGETT} -lorocos-rtt-${TARGETT}
all: main
main.o: main.cpp
$(CXX) -c main.cpp $(CXXFLAGS)
AHRS.o: AHRS.cpp AHRS.h
$(CXX) -c AHRS.cpp $(CXXFLAGS)
main: main.o AHRS.o
$(CXX) -g -o main main.o AHRS.o $(CXXFLAGS) $(LDFLAGS)
clean:
rm -f main orocos.log .tb_history *.o
But I'm used to use QtCreator. I know that QtCreator constructs its own makefile from the project (.pro) file during build process. So, I think, relevant information must be copied from the Makefile contents (above) into a Qt Creator project file to allow QtCreator to generate the compatible makefile. Right?
Given the Makefile above, how should the .pro file look like?
And in the end of this process I'll be able to work from QtCreator.
Given the Makefile above, how should the .pro file look like?
Like this:
TEMPLATE = app
TARGET = AHRS # the desired filename of the executable goes here
OROPATH = /usr/local
INCLUDEPATH += $${OROPATH}/include
O_TARGET = gnulinux
DEFINES += OROCOS_TARGET=$${O_TARGET}
QMAKE_RPATHDIR += -L$${OROPATH}/lib
LIBS += -L$${OROPATH}/lib
LIBS += -lorocos-taskbrowser-$${O_TARGET} -lorocos-rtt-$${O_TARGET}
SOURCES += main.cpp AHRS.cpp
HEADERS += AHRS.h
Note that Qt Creator doesn't construct anything. qmake does. The project files are qmake projects, not Qt Creator projects. You don't need Qt Creator at all to build your project. You can do it from the command line using nothing but Qt and the compiler/binutils:
# assume that the source is in AHRS-source subfolder
mkdir AHRS
cd AHRS
/path/to/Qt/bin/qmake ../AHRS-source
make -j
# now we can run it
./AHRS

Generating IDL entities using automake/Makefile.am

For those unfamiliar with IDL (interface description language), it abstracts data description for use across platforms (java, c, c++, etc). My project has dependencies Foo.c, Foo.h, FooHelper.c, and FooHelper.h which are generated from Foo.idl. How do I run an arbitrary command when Foo.idl changes, but still include Foo.c, FooHelper.c, in the build process?
My current attempts add a rule to the Makefile.am -- the hope is that the rule is copied over to the generated Makefile.
I have tried:
Foo.idl : Foo.idl
${the_generate_command}
and then added Foo.idl to my_program_SOURCES but it doesn't run the_generate_command when building.
I have had success generating from the IDL with
Foo.c Foo.h FooHelper.h FooHelper.c : Foo.idl
${the_generate_command}
But it won't add Foo.c, FooHelper.c to the compile process, so they're never built, just generated by the_generate_command!
All the code (including the idl) is in $PROJECT_DIR/src.
rq's answer is almost correct, but misses a couple of subtleties. Try this:
bin_PROGRAMS = myprogram
myprogram_SOURCES = Foo.c Foo.h FooHelper.h FooHelper.c $(OTHER_SOURCES)
BUILT_SOURCES = Foo.c Foo.h FooHelper.h FooHelper.c
EXTRA_DIST = Foo.idl
MAINTAINERCLEANFILES = Foo.c Foo.h FooHelper.h FooHelper.c
Foo.c: Foo.idl
$(THE_GENERATE_COMMAND)
Foo.h FooHelper.h FooHelper.c: Foo.c
#if test -f $#; then \
touch $#; \
else \
## Recover from the removal of $#
rm -rf $<; \
$(MAKE) $(AM_MAKEFLAGS) $<; \
fi
The additional rules to "generate" Foo.h, FooHelper.h and FooHelper.c from Foo.c ensure that parallel builds won't try and run $(THE_GENERATE_COMMAND) twice. It is an idiom detailed in the Automake manual which will work for parallel builds. There is still a little fragility here: if the user removes (say) FooHelper.h and FooHelper.c and starts a parallel make, it may run the $(MAKE) $(AM_MAKEFLAGS) $< recovery part of the rule multiple times in parallel. As the manual says, this race can only going to happen if the user manually mutilates the build tree, and even then it's nothing a make clean; make cannot fix.
The BUILT_SOURCES line ensures that Foo.c, Foo.h, FooHelper.h and FooHelper.c are built before trying to build myprogram (see this section of the Automake manual to see why just adding them to myprog_SOURCES is insufficient). The EXTRA_DIST variable ensures that the .idl file will be captured by make dist (reference).
MAINTAINERCLEANFILES specifies additional files to delete when running make maintainer-clean; this is to comply with the GNU Makefile Standards. See also the variable's description in the Automake manual.

Call cmake from make to create Makefiles?

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

Resources