I am trying to compile poky with QT5 for RaspberryPi3.
I found this guide: https://medium.com/#shigmas/yocto-pi-and-qt-e9f2df38a610
However, instead of morty I have decided to use dunfell branch.
I have adjusted the branch names accordingly, same with some renamed/deleted packages and paths.
I have managed to build the image almost flawlessly (QT libraries are installed; example binary - not, but it can be my fault/some compilation flags might have changed between versions; that's another topic).
However, I cannot quite put my finger on how the layers are exactly included:
if I used only bblayers.conf from my layer, bitbake would complain about not seeing raspberrypi3 as a machine definition, not being able to include some files etc.
On the other hand, if I used only bblayers.conf in build directory, then bitbake would complain about not satisfied dependencies in meta-mylayer.
I ended up with duplicating most layer entires, i.e.:
#build/conf/bblayers.conf
BBLAYERS ?= " \
/home/<username>/yoctoproject/poky/meta \
/home/<username>/yoctoproject/poky/meta-poky \
/home/<username>/yoctoproject/poky/meta-openembedded/meta-oe \
/home/<username>/yoctoproject/poky/meta-openembedded/meta-multimedia \
/home/<username>/yoctoproject/poky/meta-openembedded/meta-networking \
/home/<username>/yoctoproject/poky/meta-openembedded/meta-python \
/home/<username>/yoctoproject/poky/meta-raspberrypi \
/home/<username>/yoctoproject/poky/meta-qt5 \
/home/<username>/yoctoproject/meta-mylayer \
"
while meta-mylayer's config looks stunnigly similar
#meta-mylayer/conf/bblayers.conf
BBLAYERS ?= " \
/home/<username>/yoctoproject/poky/meta \
/home/<username>/yoctoproject/poky/meta-poky \
/home/<username>/yoctoproject/poky/meta-openembedded/meta-oe \
/home/<username>/yoctoproject/poky/meta-openembedded/meta-multimedia \
/home/<username>/yoctoproject/poky/meta-openembedded/meta-networking \
/home/<username>/yoctoproject/poky/meta-openembedded/meta-python \
/home/<username>/yoctoproject/poky/meta-raspberrypi \
/home/<username>/yoctoproject/poky/meta-qt5 \
"
Again, as I have previously stated: the whole setup seems to be working reasonably in the end, but nevertheless the layer config I have feels a bit "off", or counter-intuitive to say the least. Which part of the docs have I potentially missed (if any)?
There shouldn't be any bblayers.conf in your layer but there must be a layer.conf file in your meta layer.
You should read the official documentation Understanding and creating layers
Related
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)
I have a .pro file in which I link my libraries using:
LIBS += -L$${OUTDIR} \
-lA \
-lB \
-lC \
I have developed three libraries A, B, C and this is the fourth library I am trying to build, call it D. libD.so needs to link with others. Since I am putting everything under a bin directorty, I added -L$${OUTDIR} there so that it will look for the bin folder for finding libraries. OUTDIR is a variable I set equal to that bin dir and I am sure it is the correct directory. I print it as a message. But I get the error that libD.so can't find libB.so. I am confused here, it finds other A and C, why it can't find B? They are all under the same directory and I am adding that to library path using -L$${OUTDIR}, so. What could be the problem?
By the way, If a delete that -L$${OUTDIR} and instead add that directory directly to LD_LIBRARY_PATH, from QtCreator Projects tab and build configurations, it finds all the libraries correctly.
Remove \ after -lC
LIBS += -L$${OUTDIR} \
-lA \
-lB \
-lC
It can't find it because at the point in the build where it looks for the library, the library isn't built yet. You need to ensure that the libraries are built in the order of their dependencies.
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 have a problem with my Makefile. I downloaded opensource Qt project. Hence, when I try to compile it I got a message:
error: No rule to make target needed by stop.
In my .pro file I have relative paths to *.cpp files. So when I replace relative paths to absolute it works, another case it got me with the error above.
System is Linux.
What should I do to do this work with the relative paths?
I would use QtCreator, opening the project and then adding one of the misplaced sources (let say the first you see in .pro).
The IDE should place it with the correct relative path, as appropriate per your folder choice. After that cut'n'paste the path prefix all over the remaining places.
Anyway, path prefixes should be relative to the directory where you find the .pro. An example from an opensource project I'm using (QZXIng, a Qt port of ZXing):
SOURCES += CameraImageWrapper.cpp \
QZXing.cpp \
imagehandler.cpp \
zxing/ResultPointCallback.cpp \
zxing/ResultPoint.cpp \
zxing/Result.cpp \
...
so you could try to move the .pro file where appropriate instead of changing relative paths...
One reason for this issue is because you have removed a file which you no longer need but forgot remove from res.qrc
I had this issue and it was because I had the wrong Kit selected under Projects>Build & Run
I have the same error. My pro file was
HEADERS = \
charectertranformer.h \
filereader.h \
svgview.h \
threadfilereader.h \
serverworker.h \
renderserver.h
SOURCES = \
charectertranformer.cpp \
filereader.cpp \
main.cpp \
svgview.cpp \
threadfilereader.cpp \
serverworker.cpp \
renderserver.cpp \
QT += concurrent
QT += opengl
QT += network
QT += svg
CONFIG -= console
#CONFIG += warn_off exceptions_off
#qmake -svgviewer.pro
deleting backslash after renderserver.cpp helps me
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.