I'm trying to compile AGL guppy with Qt 5.15.
So I forked the meta-qt5.
and add my custom config qtbase_git.bbappend:
PACKAGECONFIG += "eglfs gl gles2 linuxfb kms libinput"
PACKAGECONFIG[vsp2] = "-feature-vsp2,-no-feature-vsp2,v4l-utils,libv4l"
PACKAGECONFIG += "vsp2"
PACKAGECONFIG[gbm] = "-gbm,-no-gbm,libgbm"
PACKAGECONFIG += "gbm"
the first bitbake gives error:
| cd eglfs_kms_support/ && ( test -e Makefile || /mnt/jiu/workspace_m3n-salvator-xs/build/tmp/work/aarch64-agl-linux/qtbase/5.15.1+gitAUTOINC+075d971fea-r0/recipe-sysroot-native/usr/bin/qmake -o Makefile /mnt/jiu/workspace_m3n-salvator-xs/build/tmp/work/aarch64-agl-linux/qtbase/5.15.1+gitAUTOINC+075d971fea-r0/git/src/plugins/platforms/eglfs/deviceintegration/eglfs_kms_support/eglfs_kms_support.pro -qtconf /mnt/jiu/workspace_m3n-salvator-xs/build/tmp/work/aarch64-agl-linux/qtbase/5.15.1+gitAUTOINC+075d971fea-r0/build/bin/qt.conf ) && make -f Makefile
| cd eglfs_kms_vsp2/ && ( test -e Makefile || /mnt/jiu/workspace_m3n-salvator-xs/build/tmp/work/aarch64-agl-linux/qtbase/5.15.1+gitAUTOINC+075d971fea-r0/recipe-sysroot-native/usr/bin/qmake -o Makefile /mnt/jiu/workspace_m3n-salvator-xs/build/tmp/work/aarch64-agl-linux/qtbase/5.15.1+gitAUTOINC+075d971fea-r0/git/src/plugins/platforms/eglfs/deviceintegration/eglfs_kms_vsp2/eglfs_kms_vsp2.pro -qtconf /mnt/jiu/workspace_m3n-salvator-xs/build/tmp/work/aarch64-agl-linux/qtbase/5.15.1+gitAUTOINC+075d971fea-r0/build/bin/qt.conf ) && make -f Makefile
| cd eglfs_emu/ && ( test -e Makefile || /mnt/jiu/workspace_m3n-salvator-xs/build/tmp/work/aarch64-agl-linux/qtbase/5.15.1+gitAUTOINC+075d971fea-r0/recipe-sysroot-native/usr/bin/qmake -o Makefile /mnt/jiu/workspace_m3n-salvator-xs/build/tmp/work/aarch64-agl-linux/qtbase/5.15.1+gitAUTOINC+075d971fea-r0/git/src/plugins/platforms/eglfs/deviceintegration/eglfs_emu/eglfs_emu.pro -qtconf /mnt/jiu/workspace_m3n-salvator-xs/build/tmp/work/aarch64-agl-linux/qtbase/5.15.1+gitAUTOINC+075d971fea-r0/build/bin/qt.conf ) && make -f Makefile
| Project ERROR: Unknown module(s) in QT: eglfs_kms_support-private
| Makefile:125: recipe for target 'sub-eglfs_kms_vsp2-make_first' failed
| make[5]: *** [sub-eglfs_kms_vsp2-make_first] Error 3
| make[5]: *** Waiting for unfinished jobs....
but when I re-bitbake, the error disappeared.
I think it's because I am using multi-thread(j8) and the order of dependency of qtbase recipe was wrong.
So How to avoid this?
There are two things that can make that behavior to happen, at least in my experience, both occur when you have a subdir project:
When as you said, the subdir project has a wrong order for the subprojects, you fix that arranging the order in the .pro . For this to happen it doesn't matter if you are compiling in multi-thread or not. (also you can apply the dependency solution)
When you are compiling multi-thread and one subproject finish compiling before one with precedence. You workaround that compiling again, and you fix that assigning dependencies in the subdir pro file, like this:
SUBDIRS += SubA SubB SubC SubD ...
SubC.depends = SubA SubB
Related
The following entry in my Makefile works fine:
# in Makefile
format:
source .venv/bin/activate && isort src/hercl/
source .venv/bin/activate && black src/hercl/ -l 120
source .venv/bin/activate && flake8 src/hercl/ --max-line-length 120 --ignore=W605
$ make format
..
All done! ✨ 🍰 ✨
4 files reformatted, 20 files left unchanged.
But this one does not :
# in Makefile
activate_venv:
source .venv/bin/activate
$make activate_venv
source .venv/bin/activate
make: source: No such file or directory
make: *** [activate_venv] Error 1
Why will the same command source <something> work in one target and not the other?
I'm using cmake to build some libraries, all of which generate some of their files.
I've created the generated files using add_custom_command(), but I've discovered something which seems like a false dependency. If a downstream library has a generated file and links to an upstream library, the downstream library sources will not start to compile until the upstream library is completely built. With many libraries (more than 50) in my project, this false dependency causes serialization in the build.
What's curious is that I also noticed that if an explicit add_custom_target() for the generated file is used with add_dependencies(), the false dependency no longer exists, and the files in the downstream library will compile concurrently with the ones in the upstream library. So I have a workaround, but is this expected behavior?
Using Cmake 1.19, Ninja 1.10.2.
The following is a minimal CMakeLists.txt file that shows what happens. The WORKS option conditionally adds the add_custom_target() and add_dependencies() clauses which cause it to work (quickly). The files foo.c and bar.c are empty, and I'm building in a subdirectory of the CMakeLists.txt directory.
I put a file called /tmp/x which is a wrapper around cc that sleeps to show the serialization occur:
#!/bin/bash -e
echo "mycc" $(date)
sleep 4
exec /usr/bin/cc $*
Here is the CMakeLists.txt:
cmake_minimum_required(VERSION 3.19)
project(test)
option(WORKS "false dependency gone if WORKS set to ON" OFF)
add_library(foo
foo.c
)
add_library(bar
bar.c
bargen.h
)
target_include_directories(bar PRIVATE ${CMAKE_CURRENT_BINARY_DIR})
add_custom_command(OUTPUT bargen.h
COMMAND touch bargen.h
)
if (${WORKS})
add_custom_target(generate_file
DEPENDS bargen.h
)
add_dependencies(bar generate_file)
endif()
target_link_libraries(bar PUBLIC foo)
Build it like this and you will see the serialization: bar.c will not start to compile until after foo.c has finished compiling (in fact, not until after the foo library is built). (I'm explicitly choosing '-j 4' to ensure Ninja will try to build in parallel).
cmake -DWORKS=OFF -G Ninja -DCMAKE_C_COMPILER=/tmp/x .. && ninja clean && ninja -j 4 -v | grep mycc
This shows the following output:
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/rhb/Downloads/cmake-anomaly/build
[1/1] Cleaning all built files...
Cleaning... 5 files.
mycc Sat Jan 2 15:15:25 EST 2021
mycc Sat Jan 2 15:15:29 EST 2021
Now build it like this and you'll see that bar.c compiles concurrently with foo.c:
cmake -DWORKS=ON -G Ninja -DCMAKE_C_COMPILER=/tmp/x .. && ninja clean && ninja -j 4 -v | grep mycc
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/rhb/Downloads/cmake-anomaly/build
[1/1] Cleaning all built files...
Cleaning... 5 files.
mycc Sat Jan 2 15:15:37 EST 2021
mycc Sat Jan 2 15:15:37 EST 2021
This was reported as a cmake issue and recently fixed with a new argument to add_custom_command. This fix will be released with the next cmake version (3.27).
DEPENDS_EXPLICIT_ONLY
.. versionadded:: 3.27
Indicate that the command's DEPENDS argument represents all files
required by the command and implicit dependencies are not required.
Without this option, if any target uses the output of the custom command,
CMake will consider that target's dependencies as implicit dependencies for
the custom command in case this custom command requires files implicitly
created by those targets.
Only the Ninja Generators actually use this information to remove
unnecessary implicit dependencies.
I am trying to add Postgresql as a dependency for my project for which I am using ExternalProject module to download the source from github and build, but the build step fails when running from cmake (cmake --build .). Configure step seems to succeed and if I go to the Build directory under EP_BASE and do a make it runs successfully. I get the following error during build:
<...>/Source/postgresql_external/src/common/relpath.c:21:10: fatal error: catalog/pg_tablespace_d.h: No such file or directory
21 | #include "catalog/pg_tablespace_d.h"
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make[5]: *** [<builtin>: relpath.o] Error 1
make[4]: *** [Makefile:42: all-common-recurse] Error 2
make[3]: *** [GNUmakefile:11: all-src-recurse] Error 2
My external project add looks like the following:
ExternalProject_Add(postgresql_external
GIT_REPOSITORY https://github.com/postgres/postgres.git
GIT_TAG REL_12_4
CONFIGURE_COMMAND <SOURCE_DIR>/configure --prefix=<INSTALL_DIR>
LOG_CONFIGURE 1
LOG_BUILD 1
LOG_INSTALL 1
)
This is running on Ubuntu 20.04 LTS, with cmake 3.16.3, gcc 9.3.0
try
ExternalProject_Get_Property(postgresql_external install_dir)
include_directories(${install_dir}/include)
I guess, you haven't propagate include directory to your target yet, but it is evtl. known to your system (thus successful call of manually called make)
Try the following code, it works for me. PotgreSQL uses MAKELEVEL variable to generate header files via perl. When you call make directly it works as expected. But it seems that cmake adds more levels to PotgreSQL's root make, so headers are not generated.
CONFIGURE_COMMAND ./configure <your options>
BUILD_IN_SOURCE 1
BUILD_COMMAND $(MAKE) MAKELEVEL=0
I have a project whose directory layout looks like:
- src/ #Contains main source code
- ext/ #Contains external libraries and headers from GitHub
- CMakeLists.txt
The problem is that no matter what I do, CMake always seems to pass ext/ to the compiler as a relative path, like this:
/usr/bin/c++ -I../ext mysrc.cpp
I've tried doing both:
include_directories("${PROJECT_SOURCE_DIR}/ext")
include_directories("/home/user/project/ext")
But it doesn't seem to matter. The directory is always passed to -I as ../ext.
Why does this matter? At the end of my build I invoke gcov -r <source file> which tells gcov to generate coverage reports from my source file and any relative paths found within. As a result, gcov is going into ext/ and generating reports for tons of stuff I don't care about and it's taking up a lot of time. If CMake would instead pass in -I/home/user/project/ext then gcov -r would ignore everything in ext/.
As far as I can tell from:
https://cmake.org/cmake/help/v3.13/command/include_directories.html ... this isn't possible, but maybe I'm just missing something?
Edit: This appears to be a problem with specifically the ninja generator. When using the Unix Makefiles generator, everything is passed via absolute paths.
https://gitlab.kitware.com/cmake/cmake/issues/18666
Edit2:
user#antimony:~/cmake_test$ ls
CMakeLists.txt ext src
user#antimony:~/cmake_test$ cat CMakeLists.txt
project(Hello)
add_subdirectory(src)
user#antimony:~/cmake_test$ cat src/CMakeLists.txt
include_directories(
.
${PROJECT_SOURCE_DIR}/ext
)
add_executable(hello_world hello.cpp)
user#antimony:~/cmake_test$ cat src/hello.cpp
#include <useless.h>
int main()
{
hello h;
return 0;
}
user#antimony:~/cmake_test$ cat ext/useless.h
struct hello {
int x;
};
user#antimony:~/cmake_test$ ~/Downloads/cmake-3.13.1-Linux-x86_64/bin/cmake --version
cmake version 3.13.1
CMake suite maintained and supported by Kitware (kitware.com/cmake).
user#antimony:~/cmake_test$ mkdir build && cd build
user#antimony:~/cmake_test/build$ ~/Downloads/cmake-3.13.1-Linux-x86_64/bin/cmake .. -G Ninja
-- The C compiler identification is GNU 7.3.0
-- The CXX compiler identification is GNU 7.3.0
...
-- Build files have been written to: /home/user/cmake_test/build
user#antimony:~/cmake_test/build$ ninja -v
[1/2] /usr/bin/c++ -I../src/. -I../ext -MD -MT src/CMakeFiles/hello_world.dir/hello.o -MF src/CMakeFiles/hello_world.dir/hello.o.d -o src/CMakeFiles/hello_world.dir/hello.o -c ../src/hello.cpp
[2/2] : && /usr/bin/c++ -rdynamic src/CMakeFiles/hello_world.dir/hello.o -o src/hello_world && :
user#antimony:~/cmake_test/build$ cat build.ninja
# CMAKE generated file: DO NOT EDIT!
# Generated by "Ninja" Generator, CMake Version 3.13
# This file contains all the build statements describing the
# compilation DAG.
...
#############################################
# Order-only phony target for hello_world
build cmake_object_order_depends_target_hello_world: phony || src/CMakeFiles/hello_world.dir
build src/CMakeFiles/hello_world.dir/hello.o: CXX_COMPILER__hello_world ../src/hello.cpp || cmake_object_order_depends_target_hello_world
DEP_FILE = src/CMakeFiles/hello_world.dir/hello.o.d
INCLUDES = -I../src/. -I../ext
OBJECT_DIR = src/CMakeFiles/hello_world.dir
OBJECT_FILE_DIR = src/CMakeFiles/hello_world.dir
TARGET_COMPILE_PDB = src/CMakeFiles/hello_world.dir/
TARGET_PDB = src/hello_world.pdb
# =============================================================================
# Link build statements for EXECUTABLE target hello_world
The example shows what may be considered an in-source build. That is when the build directory is the same or a sub-directory of the src folder (not that there is a hard definition or anything, but this does trigger the ninja issue of using relative paths on the command line). Try mkdir ~/cmake_build && cd ~/cmake_build && cmake ~/cmake_test then it should use absolute paths for everything.
Either way there really isn't a specific way to force one or the other. In general cmake generators will use absolute paths for everything that ends up used on the command line. There seems to be issues with Ninja that prevent the generator from using absolute paths for in-source builds (https://github.com/ninja-build/ninja/issues/1251).
I have checked out the project on two different platforms and they give me -
on Ubuntu (have installed cmake and ccmake)
$ make
cd .build && make --no-print-directory
make[1]: *** No targets specified and no makefile found. Stop.
make: *** [all] Error 2
on Mac OS X (it starts off ...)
$ make
touch .configured
cd .build && cmake ..
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
It seems like Ubuntu is still trying to compile using make?
cmake is a generator for build-system control files. It does not drive the build by itself, but is relies on external tools like make, nmake or some GUIs to build the software. The cd .build && cmake .. line in the osx build only updates the build system files, the build itself is driven by make there.
The error on the ubunto box probably is that there is no Makefile in .build, which means that cmake wasn't executed there, or it failed there previously. You can run cmake by hand with cd .build && cmake ...
If there's a configure script in the project, can you try:
./configure
make