[PATCH] README.rst: remove unnecessary dependency for qcam
Quentin Schulz
quentin.schulz at cherry.de
Tue Apr 22 11:21:44 CEST 2025
Hi Kieran,
On 3/17/25 3:51 PM, Quentin Schulz wrote:
> Hi Kieran,
>
> On 3/17/25 2:10 PM, Kieran Bingham wrote:
>> Quoting Quentin Schulz (2025-03-17 12:30:48)
>>> Hi Kieran,
>>>
>>> On 3/17/25 1:21 PM, Kieran Bingham wrote:
>>>> Quoting Quentin Schulz (2025-03-11 13:06:25)
>>>>> +Cc Ricardo, the original commit author, in case I'm missing something
>>>>>
>>>>> On 3/11/25 2:01 PM, Quentin Schulz wrote:
>>>>>> [foss+libcamera at 0leil.net appears similar to someone who
>>>>>> previously sent you email, but may not be that person. Learn why
>>>>>> this could be a risk at https://aka.ms/
>>>>>> LearnAboutSenderIdentification ]
>>>>>>
>>>>>> From: Quentin Schulz <quentin.schulz at cherry.de>
>>>>>>
>>>>>> The introducing commit (dff416a84b78 ("README: Add missing package
>>>>>> for
>>>>>> Qt5 tools"); for Qt 5 originally) stated that without the
>>>>>> dependency we
>>>>>> would get the following messages:
>>>>>>
>>>>>> Program /usr/lib/x86_64-linux-gnu/qt5/bin/lrelease found: NO
>>>>>> Program lrelease-qt5 found: NO
>>>>>> Program lrelease found: NO found but need: '== 5.14.2'
>>>>>>
>>>>>> That is still the case but this actually is neither breaking the
>>>>>> build
>>>>>> nor is it doing anything to the outcome of the build as qcam is
>>>>>> bit to
>>>>>> bit identical with and without that package.
>>>>>>
>>>>>> Therefore, let's not mislead users to install an unnecessary package.
>>>>>>
>>>>>> Signed-off-by: Quentin Schulz <quentin.schulz at cherry.de>
>>>>>> ---
>>>>>> This was tested within a debian:bookworm container with and
>>>>>> without the
>>>>>> package, checked out both at master and introducing commit. qcam
>>>>>> is bit
>>>>>> to bit identical in both cases.
>>>>
>>>> That's the evidence I would look for in this, so
>>>>
>>>> Reviewed-by: Kieran Bingham <kieran.bingham at ideasonboard.com>
>>>>
>>>> Is this still the case on Qt6? I assume/infer that the reason you want
>>>> to remove this dependency is because something has changed in qt6 ?
>>>>
>>>> If so - adding that to the commit message would help clarify things, as
>>>> you are removing a qt6 package, but only discussing qt5 in the commit.
>>>>
>>>
>>> This was tested for both qt5 and qt6, results are both bit to bit
>>> identical.
>>>
>>> I stated that in the Buildroot patch:
>>> https://eur02.safelinks.protection.outlook.com/?
>>> url=https%3A%2F%2Flore.kernel.org%2Fbuildroot%2F20250311-libcamera-
>>> qt6-
>>> v1-1-4897aadc6fe3%40cherry.de%2F&data=05%7C02%7Cquentin.schulz%40cherry.de%7C2f082d52936f4a81ed5808dd65552053%7C5e0e1b5221b54e7b83bb514ec460677e%7C0%7C0%7C638778138464717991%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=b3bBcP2OYapWwhMwAoAMgIKTLcg8rurpdOnKqW6XzwQ%3D&reserved=0
>>> but forgot to add it here before submitting the patch.
>>>
>>> I can reword the commit log to something like:
>>>
>>> """
>>> The introducing commit (dff416a84b78 ("README: Add missing package for
>>> Qt5 tools"); for Qt 5 originally) stated that without the dependency we
>>> would get the following messages:
>>>
>>> Program /usr/lib/x86_64-linux-gnu/qt5/bin/lrelease found: NO
>>> Program lrelease-qt5 found: NO
>>> Program lrelease found: NO found but need: '== 5.14.2'
>>>
>>> That was the case for qt5 and is still true for qt6 but this actually
>>> is neither breaking the build nor is it doing anything to the outcome
>>> of the build (for both qt5 and qt6) as qcam is bit to bit identical
>>> with and without that package.
>>>
>>> Therefore, let's not mislead users to install an unnecessary package.
>>> """
>>>
>>> Would that work for you? Do you want me to send a v2 for that?
>>
>> No need for a v2 at the moment ... we can easily fix up the commit, it's
>> just the justification I want to get right. Stating that this is still
>> the case for Qt6 fixes my concern ;-)
>>
>> Especially as this will now cause users to have a warning reintroduced
>> in their setup logs! Why is that now acceptable when it wasn't before?
>>
>
> """
> meson setup build
> The Meson build system
> Version: 1.0.1
> Source dir: /home/qschulz/work/upstream/libcamera
> Build dir: /home/qschulz/work/upstream/libcamera/build
> Build type: native build
> Project name: libcamera
> Project version: 0.3.0
> C compiler for the host machine: cc (gcc 12.2.0 "cc (Debian 12.2.0-14)
> 12.2.0")
> C linker for the host machine: cc ld.bfd 2.40
> C++ compiler for the host machine: c++ (gcc 12.2.0 "c++ (Debian
> 12.2.0-14) 12.2.0")
> C++ linker for the host machine: c++ ld.bfd 2.40
> Host machine cpu family: x86_64
> Host machine cpu: x86_64
> Header "fcntl.h" has symbol "F_ADD_SEALS" : YES
> Header "unistd.h" has symbol "issetugid" : NO
> Header "locale.h" has symbol "locale_t" : YES
> Header "sys/mman.h" has symbol "memfd_create" : YES
> Header "stdlib.h" has symbol "secure_getenv" : YES
> Compiler for C supports arguments -Wno-c99-designator: NO
> Found pkg-config: /usr/bin/pkg-config (1.8.1)
> Did not find CMake 'cmake'
> Found CMake: NO
> Run-time dependency lttng-ust found: NO (tried pkgconfig and cmake)
> Program ./parser.py found: YES (/home/qschulz/work/upstream/libcamera/
> utils/ipc/./parser.py)
> Program ./generate.py found: YES (/home/qschulz/work/upstream/libcamera/
> utils/ipc/./generate.py)
> Program ./extract-docs.py found: YES (/home/qschulz/work/upstream/
> libcamera/utils/ipc/./extract-docs.py)
> Program ./gen-tp-header.py found: YES (/home/qschulz/work/upstream/
> libcamera/utils/tracepoints/./gen-tp-header.py)
> Configuring version.h using configuration
> Program openssl found: YES (/usr/bin/openssl)
> Library atomic found: YES
> Run-time dependency threads found: YES
> Run-time dependency libdw found: NO (tried pkgconfig and cmake)
> Run-time dependency libunwind found: NO (tried pkgconfig and cmake)
> Header "execinfo.h" has symbol "backtrace" : YES
> Checking for function "dlopen" : YES
> Run-time dependency libudev found: NO (tried pkgconfig and cmake)
> Run-time dependency yaml-0.1 found: YES 0.2.5
> Run-time dependency gnutls found: YES 3.7.9
> Dependency libexif skipped: feature android disabled
> Dependency libjpeg skipped: feature android disabled
> Run-time dependency libevent_pthreads found: NO (tried pkgconfig and cmake)
> Run-time dependency libevent_pthreads found: NO (tried pkgconfig and cmake)
> Run-time dependency libtiff-4 found: YES 4.5.0
> Run-time dependency GTest found: NO (tried pkgconfig and system)
> Looking for a fallback subproject for the dependency gtest
>
> Executing subproject gtest
>
> gtest| Project name: gtest
> gtest| Project version: 1.11.0
> gtest| C++ compiler for the host machine: c++ (gcc 12.2.0 "c++ (Debian
> 12.2.0-14) 12.2.0")
> gtest| C++ linker for the host machine: c++ ld.bfd 2.40
> gtest| Dependency threads found: YES unknown (cached)
> gtest| Dependency threads found: YES unknown (cached)
> gtest| Dependency threads found: YES unknown (cached)
> gtest| Dependency threads found: YES unknown (cached)
> gtest| Build targets in project: 35
> gtest| Subproject gtest finished.
>
> Dependency gtest from subproject subprojects/googletest-release-1.11.0
> found: YES 1.11.0
> Run-time dependency qt5 (modules: Core, Gui, Widgets) found: YES 5.15.8
> (pkg-config)
> Header "QOpenGLWidget" has symbol "QOpenGLWidget" with dependencies
> Qt5Core, Qt5Core, Qt5Gui, Qt5Widgets: YES
> Detecting Qt5 tools
> Run-time dependency qt5 (modules: Core) found: YES 5.15.8 (pkg-config)
> Program /usr/lib/x86_64-linux-gnu/qt5/bin/moc found: YES 5.15.8 (/usr/
> lib/x86_64-linux-gnu/qt5/bin/moc)
> Program /usr/lib/x86_64-linux-gnu/qt5/bin/uic found: YES 5.15.8 (/usr/
> lib/x86_64-linux-gnu/qt5/bin/uic)
> Program /usr/lib/x86_64-linux-gnu/qt5/bin/rcc found: YES 5.15.8 (/usr/
> lib/x86_64-linux-gnu/qt5/bin/rcc)
> Program /usr/lib/x86_64-linux-gnu/qt5/bin/lrelease found: NO
> Program lrelease5 found: NO
> Program lrelease-qt5 found: NO
> Program lrelease found: NO found but need: '== 5.15.8' (/usr/bin/lrelease)
> Run-time dependency glib-2.0 found: NO (tried pkgconfig and cmake)
> Run-time dependency gstreamer-video-1.0 found: NO (tried pkgconfig and
> cmake)
> Run-time dependency gstreamer-allocators-1.0 found: NO (tried pkgconfig
> and cmake)
> Run-time dependency python3 found: NO (tried pkgconfig and sysconfig)
> Program doxygen found: NO
> Program dot found: NO
> Program sphinx-build-3 found: NO
> Program sphinx-build found: NO
> Configuring config.h using configuration
> Program python3 (jinja2, ply, jinja2, yaml) found: YES (/usr/bin/
> python3) modules: jinja2, ply, jinja2, yaml
> Build targets in project: 39
>
> libcamera 0.3.0
>
> Versions
> Sources : 0.3.0
>
> Paths
> LIBCAMERA_DATA_DIR : "/usr/local/share/libcamera"
> LIBCAMERA_SYSCONF_DIR : "/usr/local/etc/libcamera"
> IPA_PROXY_DIR : "/usr/local/libexec/libcamera"
> IPA_CONFIG_DIR : "/usr/local/etc/libcamera/ipa:/usr/
> local/share/libcamera/ipa"
> IPA_MODULE_DIR : "/usr/local/lib/x86_64-linux-gnu/libcamera"
>
> Configuration
> SoftISP support : False
> IPA modules signed with : gnutls
> Enabled pipelines : ipu3
> uvcvideo
> Enabled IPA modules : ipu3
> Controls files : control_ids_draft.yaml
> control_ids_core.yaml
> Properties files : property_ids_draft.yaml
> property_ids_core.yaml
> Hotplug support : NO
> Tracing support : NO
> Android support : NO
> GStreamer support : NO
> Python bindings : NO
> V4L2 emulation support : NO
> cam application : NO
> qcam application : YES
> lc-compliance application: NO
> Unit tests : NO
>
> Subprojects
> gtest : YES
> """
>
> There are plenty other "NO" printed during the setup detection. Does it
> really matter if one gets a few other "NO" especially since they don't
> impact anything?
>
>> Is there anything we can do to stop meson from looking for lrelease-qt5?
>
> Doesn't seem like it no.
>
> I'm not familiar with meson nor qt build systems but it seems like
> QtBaseModule in mesonbuild/modules/qt.py has a hardcoded list of tools
> to check. In Debian Bookworm, meson 1.0.1 is used. QtBaseModule has
> self.tools set to moc, uic, rcc and lrelease. The compilers_detect
> method checks for all binaries listed in that list (c.f.
> find_program()). That method is called when _detect_tools() method is
> called. That method seems to be called whenever _compile_moc_impl(),
> _compile_resources_impl, or _compile_ui_impl() is called. Those are
> called when compile_resources(), compile_ui(), compile_moc() or
> preprocess() is called. Which is what we do in src/apps/qcam/
> meson.build, c.f.
>
> """
> resources = qt5.preprocess(moc_headers : qcam_moc_headers,
> qresources : qcam_resources,
> dependencies : qt5_dep)
>
> qcam = executable('qcam', qcam_sources, resources,
> """
>
> Note that it seems meson v1.7.0 will also check for qmlcachegen and
> qmltyperegistrar on the host, c.f. commit
> 4508622a34932d23e336392a8a3c71ed79af4e3f.
>
> has_tools now allows to pass a list of tools to check, c.f. commit
> 6797f9bc1502609783a8fc465e2960819ab4f38f but that doesn't seem to change
> the list of tools that are always checked, just a way to provide a way
> to conditionally do things in meson, based on the return value of
> has_tools for specific tools, my understanding is that all hardcoded
> tools are still checked once.
>
>> Who's looking for that in the build?
>>
>
> meson, based on the preprocess() call in the qt module. We need that
> apparently for moc (header files with Q_OBJECT in there? c.f. https://
> doc.qt.io/qt-6/moc.html) and rcc (handling .qrc files, c.f. https://
> doc.qt.io/qt-6/rcc.html).
>
> We may want to use qt.has_tools() with moc and rcc to manually check
> those before we call preprocess() and fail otherwise? So people are
> aware which qt tools are actually required? But that still wouldn't
> remove the "NO" for lrelease, and other unneeded binaries. Note that moc
> and rcc (and uic, another Qt tool that is required) are part of qtbase5-
> dev-tools package on Debian (not to be confused with qttools5-dev-tools
> which is bringing in lrelease (and lupdate, lconvert, ...)).
>
Anything I can help with to get this merged? Or do we abandon it? Just
to know what to do with this patch that I am occasionally still
monitoring :)
Cheers,
Quentin
More information about the libcamera-devel
mailing list