Assorted quality of life fixes and introduce --no-gui option#41
Assorted quality of life fixes and introduce --no-gui option#41idlethread wants to merge 28 commits into
Conversation
Signed-off-by: Amit Kucheria <amit.kucheria@oss.qualcomm.com>
The single-level glob missed libftd2xx-static.a when the archive uses a different subdirectory depth. GLOB_RECURSE finds it regardless. Also adds a fatal error if the library is absent so the failure is clear. Signed-off-by: Amit Kucheria <amit.kucheria@oss.qualcomm.com>
OUTPUT_SCRIPT was added in Qt 6.5; older system Qt (e.g. Ubuntu 24.04 ships 6.4.2) only knows FILENAME_VARIABLE. Add a qtac_deploy_app() macro in src/applications/CMakeLists.txt that selects the right argument name based on Qt6Core_VERSION, and replace all eight call sites with it. Signed-off-by: Amit Kucheria <amit.kucheria@oss.qualcomm.com>
stateChanged(int) is deprecated-as-error in Qt 6.7+ (Debian 12); checkStateChanged(Qt::CheckState) was not added until Qt 6.7 and does not exist on Ubuntu 24.04's system Qt (6.4). Use QT_VERSION_CHECK to select the right signal at compile time. Signed-off-by: Amit Kucheria <amit.kucheria@oss.qualcomm.com>
target_link_directories was using a hardcoded Windows-specific
__Builds/x64/$<CONFIG>/lib path in every application and library
CMakeLists.txt. On Linux this produced a spurious "search path not
found" linker warning. Replace with ${STATIC_LIBPATH}, which is
already set correctly per platform by the included Common.cmake.
Signed-off-by: Amit Kucheria <amit.kucheria@oss.qualcomm.com>
Avoids output directory conflicts when building for multiple distros side-by-side (e.g. in CI containers) and allows keeping macOS and Linux builds on the same checkout. Unsupported platforms now get an explicit error instead of silently inheriting a wrong DISTRO value. Signed-off-by: Amit Kucheria <amit.kucheria@oss.qualcomm.com>
Use nproc on Linux and sysctl -n hw.logicalcpu on Darwin to pass --parallel to cmake --build. Unparallelized builds on an 8-core machine took ~4x longer with no benefit. Signed-off-by: Amit Kucheria <amit.kucheria@oss.qualcomm.com>
--pristine deletes build/, __Builds/, and cached third-party download archives (.tgz/.zip) before configuring. --incremental skips all deletion so cmake reuses the existing tree and already-downloaded libraries. Pristine remains the default to preserve prior behaviour. Signed-off-by: Amit Kucheria <amit.kucheria@oss.qualcomm.com>
Without an APPLE branch, macOS (which is UNIX but not WIN32) fell into the Linux else() and set CONFIGURATION to "Linux/Debug|Release". Add elseif(APPLE) to produce "macOS/Debug|Release" so build outputs land in __Builds/macOS/ rather than __Builds/Linux/. Signed-off-by: Amit Kucheria <amit.kucheria@oss.qualcomm.com>
Without an APPLE branch, macOS downloaded and linked the Linux ELF libftd2xx.a, causing a "not a mach-o file" linker error. Add APPLE handling throughout third-party/CMakeLists.txt: - Platform selection: use D2XX1.4.30.dmg (present locally in third-party/; downloaded from ftdichip.com if absent) - Download: preserve existing DMG; skip cmake -E tar validation which fails on disk images - Extraction: mount with hdiutil, copy the Mach-O universal libftd2xx.a, then detach - link_ftd2xx(): link only ftd2xx on APPLE; pthread and dl are in macOS libSystem and need not be listed explicitly Signed-off-by: Amit Kucheria <amit.kucheria@oss.qualcomm.com>
libftd2xx.a bundles darwin_usb.o which calls into CoreFoundation and IOKit. Eight targets in src/ link ftd2xx directly rather than through link_ftd2xx(), so adding the frameworks only to that helper was insufficient. Attach the frameworks as INTERFACE_LINK_LIBRARIES on the ftd2xx IMPORTED target instead. CMake propagates them automatically to every consumer regardless of how ftd2xx is referenced. Signed-off-by: Amit Kucheria <amit.kucheria@oss.qualcomm.com>
Both FTDITemplateCompiler.cpp and UpdateDeviceList.cpp defined per-platform constants under #ifdef Q_OS_WIN / #ifdef Q_OS_LINUX with no macOS branch, causing "undeclared identifier" compile errors. FTDITemplateCompiler: remove the compile-time xmlTemplatePath global entirely and compute it at runtime in load() using QCoreApplication::applicationDirPath(). The template is deployed alongside the executable on all platforms, so this works correctly everywhere without hardcoded paths. UpdateDeviceList: kServerConfigDir is a developer-workspace fallback path that cannot be generalised to macOS. Consolidate the two separate in write() with the same condition so macOS falls through directly to tacConfigRoot(). Signed-off-by: Amit Kucheria <amit.kucheria@oss.qualcomm.com>
The macro used #ifdef __linux__ to guard the __attribute__ path, so macOS fell through to __declspec which clang rejects without -fdeclspec. Replace the _WIN32/else fallthrough with explicit _WIN32 / __linux__ || __APPLE__ branches and a #error guard for unsupported platforms, matching the explicit platform dispatch convention used in CMake throughout the project. Signed-off-by: Amit Kucheria <amit.kucheria@oss.qualcomm.com>
Allows building against system Qt on Debian 12 and Ubuntu 24.04 (both ship Qt 6.8); previously required 6.9 which forced the Qt Online Installer even on current LTS distros that ship 6.8. Signed-off-by: Amit Kucheria <amit.kucheria@oss.qualcomm.com>
Headless environments (servers, CI) and SDK-only consumers do not need the Qt GUI stack. --no-gui sets BUILD_UI=OFF, skipping Qt Multimedia, Widgets, qcommon, ui-common, and all GUI applications; only QCommonConsole and TACDev are compiled, with a correspondingly smaller Qt dependency footprint. Signed-off-by: Amit Kucheria <amit.kucheria@oss.qualcomm.com>
Release is always built. Debug is only built when --debug is passed, avoiding unnecessary build time during routine builds. Signed-off-by: Amit Kucheria <amit.kucheria@oss.qualcomm.com>
qt_add_library() without a type keyword defaults to BUILD_SHARED_LIBS (dynamic if that variable is set); STATIC makes the intent explicit and is required for the cmake install target to export a usable archive. Without STATIC, cmake --install fails trying to install the non-existent CMakeRelink copy of the .so. Signed-off-by: Amit Kucheria <amit.kucheria@oss.qualcomm.com>
Allows SDK consumers to use cmake --install to deploy the C++ interface library and headers without building from source. Installs TACDev library, TACDev.h, QCommonConsole library, and device configurations to their standard CMAKE_INSTALL_* destinations. Signed-off-by: Amit Kucheria <amit.kucheria@oss.qualcomm.com>
This will install the TACDev libraries and various binaries so they don't need to be run from the build directory. Runs cmake --install on the Release build tree when --install is passed. Installs to CMAKE_INSTALL_PREFIX (default /usr/local on Linux/macOS, C:/Program Files/<project> on Windows); override by setting -DCMAKE_INSTALL_PREFIX at configure time. What gets installed: - Static libraries (QCommonConsole, QCommon, ui-common, TACDev) → lib/ - Public header (TACDev.h) → include/qtac/ - Applications (TAC, devlist, tacdump, etc.) → bin/ - Board configurations (.tcnf) → share/qtac/configurations/ - FTDI D2XX static library → lib/ (via new install rule in third-party/CMakeLists.txt) - Desktop entries and icons (Linux) → share/applications/, share/icons/ Signed-off-by: Amit Kucheria <amit.kucheria@oss.qualcomm.com>
Qt requires .app bundles for GUI applications; plain executables are not supported by macdeployqt or qt_generate_deploy_app_script. Add MACOSX_BUNDLE to the three GUI targets (TAC, TACConfigEditor, DeviceCatalog) via qt_add_executable(). CLI tools (DevList, TACDump, FTDICheck, UpdateDeviceList, LITEProgrammer) must remain plain executables; wrapping them in bundles causes macdeployqt to chase transitive QtPdf/QtSvg framework dependencies that are absent from split Homebrew Qt installations. Signed-off-by: Amit Kucheria <amit.kucheria@oss.qualcomm.com>
The Qt deploy tool on Linux copies all runtime dependencies (Qt shared libs, libEGL, libFLAC, even ld-linux-aarch64.so.1) into the install prefix. This is appropriate for portable bundles like AppImage but wrong for system installs to /usr/local where Qt and system libraries are already provided by the distro package manager. Restrict the deploy script to WIN32 and APPLE only. Windows needs Qt DLLs next to the executable; macOS needs frameworks bundled inside the .app. Linux system installs need neither. On Linux we instead install qt.conf on Linux to fix missing platform plugin Without the Qt deploy script, installed binaries have no qt.conf and Qt reports an empty plugin path at runtime, causing the 'could not find platform plugin xcb' error. Query qmake for QT_INSTALL_PLUGINS at configure time and install a qt.conf next to the binaries. This works for both apt Qt (/usr/lib/<arch>/qt6/plugins) and aqtinstall without copying any runtime libraries into the install prefix. Signed-off-by: Amit Kucheria <amit.kucheria@oss.qualcomm.com>
macdeployqt/windeployqt run for every app on every install and copy hundreds of MB of Qt frameworks, making --install very slow. For release testing this is unnecessary -- apps can run against the system Qt using the rpath already added on macOS. Add DEPLOY_APPS cmake option (default OFF) that gates the deploy scripts. Add --deploy flag to build.sh and build.bat that passes -DDEPLOY_APPS=ON at configure time. Normal workflow: ./build.sh --install # fast: installs binaries only ./build.sh --install --deploy # slow: full Qt bundling for distribution Signed-off-by: Amit Kucheria <amit.kucheria@oss.qualcomm.com>
Previously --pristine deleted the entire build/ and __Builds/ trees, wiping out any other platform's build (e.g. a macOS build while cleaning for a Debian rebuild). On Linux/macOS, delete only build/<distro>/ and __Builds/<platform>/: Linux debian: build/debian/ __Builds/Linux-debian/ macOS: build/macOS/ __Builds/macOS/ Introduce BUILDS_SUBDIR alongside DISTRO in the uname case block to hold the __Builds prefix (Linux-<id> vs macOS). On Windows, scope the clean to build\Debug, build\Release, and __Builds\x64 rather than the entire tree. Signed-off-by: Amit Kucheria <amit.kucheria@oss.qualcomm.com>
--pristine/--incremental and --debug are useful during development --install and --deploy are useful for end users to deploy QTAC --no-gui to only build the core libraries w/o the UI applications build.bat has no --no-gui flag; Windows no-GUI builds use BUILD_UI=OFF directly on the cmake command line. Signed-off-by: Amit Kucheria <amit.kucheria@oss.qualcomm.com>
List all packages needed before running build.sh: cmake 3.16+, build-essential (GCC 11+), ninja-build; document all three Qt install paths (apt for Ubuntu 24.04+, Qt Online Installer, aqtinstall) with a note that Ubuntu 22.04 system Qt is too old; add the reduced package set for --no-gui builds; add the missing udevadm trigger step; document QTBIN for both apt and installer layouts. Signed-off-by: Amit Kucheria <amit.kucheria@oss.qualcomm.com>
Signed-off-by: Amit Kucheria <amit.kucheria@oss.qualcomm.com>
Document Xcode Command Line Tools, cmake, and Qt 6.8+ installation for macOS; note that FTDI D2XX is auto-downloaded via hdiutil at configure time; remove obsolete make note (ninja-build is now listed in prerequisites). Signed-off-by: Amit Kucheria <amit.kucheria@oss.qualcomm.com>
For each platform (Linux, Windows, macOS), list every path installed by 'cmake --install': binaries, static libraries (libTACDev.a, libftd2xx.a), public header (TACDev.h), device configurations, desktop files, icons, and qt.conf. Note the RPATH strategy on Linux/macOS, the Administrator requirement on Windows, and the Qt DLL caveat when --deploy is not used. Signed-off-by: Amit Kucheria <amit.kucheria@oss.qualcomm.com>
| endif() | ||
|
|
||
| qt_add_library(${LIBRARY_NAME} | ||
| qt_add_library(${LIBRARY_NAME} STATIC |
There was a problem hiding this comment.
@idlethread would like to understand if the change is intentional and if you're facing an issue with the library being dynamic. This will break the dynamic loading of library in python interfaces
| #include "PlatformID.h" | ||
|
|
||
| // Qt | ||
| #include <QCoreApplication> |
There was a problem hiding this comment.
Redundant code. Please include AppCore.h from QCommonConsole
| { | ||
| bool result{false}; | ||
| const QString xmlTemplatePath = | ||
| QCoreApplication::applicationDirPath() + QStringLiteral("/ftdi-template.xml"); |
There was a problem hiding this comment.
Replace QCoreApplication with AppCore::applicationBinPath()
There was a problem hiding this comment.
As I understand, the --no-gui option support is available for builds using CLI only. This breaks the UI build process as several variables will not be defined. Is it possible to create a build workflow for both CLI and Qt Creator with minimal setup requirements?
There was a problem hiding this comment.
As I understand, the --no-gui option support is available for builds using CLI only. This breaks the UI build process as several variables will not be defined. Is it possible to create a build workflow for both CLI and Qt Creator with minimal setup requirements?
There was a problem hiding this comment.
- Is this PR validated on MacOS for correctness?
- Why are we asking users to downgrade Qt to 6.8 from 6.9?
- Was Visual Studio 2022 guide not clear in its previous form?
- We have a separate documentation for installation using Qt GUI. Does that not help?
- The readme seems over explained. The PR description outlines to add --no-gui flag but introduces several others
- Each of these flags, will require a separate review on their effectiveness in the build process
| #ifdef Q_OS_LINUX | ||
| #elif defined(Q_OS_LINUX) | ||
| const QString kServerConfigDir = expandPath("/local/mnt/workspace/github/open-source/qcom-test-automation-controller/configurations"); | ||
| #endif |
There was a problem hiding this comment.
Why are we hardcoding the platform here?
| } | ||
| else | ||
| { | ||
| #if defined(Q_OS_WIN) || defined(Q_OS_LINUX) |
| # On Windows/macOS the deploy step is opt-in via -DDEPLOY_APPS=ON (or --deploy | ||
| # in build.sh/build.bat) to avoid slow macdeployqt/windeployqt runs during | ||
| # routine testing. | ||
| macro(qtac_deploy_app target) |
There was a problem hiding this comment.
Using this macro in dependent projects breaks users from individually compiling component applications. Why is this hardening required?
There was a problem hiding this comment.
How is project depolyment on Linux handled? Is the Linux approach validated for correctness?
Pull Request
Description
This pull request fixes issues to:
Type of Change
Checklist
Additional Context
I do not have any access to Windows. I'm looking for help reviewing the changes on Windows.