From eb4c49e1b26aa5022331c99bb46d79e320edb686 Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Thu, 27 Nov 2025 23:16:30 +0100 Subject: [PATCH] Build: upgrade, tighten and document the prerequisites MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Many versions enforced with this changeset are chosen such as to support Ubuntu/Noble (24.04) and otherwise use versions reasonably close to Debian-Trixie (≙reference-platform) Since we now require a fairly modern compiler for C++23, I have added now an explicit version check, which however is performed only if the defined compiler is named `g++*` Furthermore, I combed through all of our build tutorials and documentation pages and updated a lot of information regarding dependencies and build practices... --- admin/scons/Platform.py | 43 ++- admin/scons/Setup.py | 6 +- doc/technical/build/BuildDependencies.txt | 159 ++++++++--- doc/technical/build/SCons.txt | 2 +- doc/user/tutorials/DebianBuilding.txt | 2 +- doc/user/tutorials/building.txt | 59 ++-- doc/user/tutorials/contributing.txt | 49 +++- wiki/thinkPad.ichthyo.mm | 321 +++++++++++++++++----- 8 files changed, 472 insertions(+), 169 deletions(-) diff --git a/admin/scons/Platform.py b/admin/scons/Platform.py index 9edc7de0b..ea11fd9c3 100644 --- a/admin/scons/Platform.py +++ b/admin/scons/Platform.py @@ -35,6 +35,23 @@ def configure(env): if not conf.TryAction('pkg-config --version > $TARGET')[0]: problems.append('We need pkg-config for including library configurations, exiting.') + # A special check in case we are compiling with GCC... + compiler = env.subst('$CXX') + verGCCmin = (14,) # note no trailing zero for version ordering check + expectedFeature = 'solid C++23 support' + if compiler.startswith("g++"): + # verify sufficient compiler version + try: + import subprocess + res = subprocess.check_output([compiler,'-dumpversion'], universal_newlines=True).strip() + res = tuple(int(x) for x in res.split('.')) + except Exception: + res = None + # + if res and res < verGCCmin: + problems.append('The compiler "%s" reports version %s, yet we need at least %s for %s.' + % (compiler, res, verGCCmin, expectedFeature)) + if not conf.CheckLibWithHeader('m', 'math.h','C'): problems.append('Did not find math.h / libm.') @@ -60,7 +77,7 @@ def configure(env): print('Valgrind not found. The use of Valgrind is optional; building without.') if not conf.CheckPkgConfig('nobugmt', 201008.1): - problems.append('Did not find NoBug [http://nobug.pipapo.org/].') + problems.append('Did not find NoBug [https://nobug.pipapo.org/].') else: conf.env.mergeConf('nobugmt') @@ -84,45 +101,45 @@ def configure(env): problems.append('We need boost::program_options (including binary lib for linking).') - if not conf.CheckPkgConfig('gavl', '1.4'): + if not conf.CheckPkgConfig('gavl', '2.0'): problems.append('Did not find Gmerlin Audio Video Lib [https://github.com/bplaum/gavl].') else: conf.env.mergeConf('gavl') - if not conf.CheckPkgConfig('alsa', '1.0.23'): + if not conf.CheckPkgConfig('alsa', '1.2'): problems.append('Support for ALSA sound output is required') - if not conf.CheckPkgConfig('gtkmm-3.0', '3.10'): + if not conf.CheckPkgConfig('gtkmm-3.0', '3.20'): problems.append('Unable to configure the mm-bindings for GTK-3') - if not conf.CheckPkgConfig('glibmm-2.4', '2.39'): + if not conf.CheckPkgConfig('glibmm-2.4', '2.66'): problems.append('Unable to configure the mm-bindings for Glib') - if not conf.CheckPkgConfig('sigc++-2.0', '2.2.10'): + if not conf.CheckPkgConfig('sigc++-2.0', '2.12'): problems.append('Need the signal-slot-binding library SigC++2') - if not conf.CheckPkgConfig('glib-2.0', '2.40'): + if not conf.CheckPkgConfig('glib-2.0', '2.80'): problems.append('Need a suitable Glib version.') - if not conf.CheckPkgConfig('gthread-2.0', '2.40'): + if not conf.CheckPkgConfig('gthread-2.0', '2.80'): problems.append('Need gthread support lib for Glib based thread handling.') - if not conf.CheckPkgConfig('cairomm-1.0', '1.10'): + if not conf.CheckPkgConfig('cairomm-1.0', '1.14'): problems.append('Unable to configure Cairo--') - verGDL = '3.8' # lowered requirements to allow building on Ubuntu/Trusty & Mint (was originally '3.12') + verGDL = '3.40' # now orphaned and thus directly provided from Lumiera.org -> can require latest available verGDLmm = '3.7.3' - urlGDLmm = 'http://ftp.gnome.org/pub/GNOME/sources/gdlmm/' + urlGDLmm = 'git://git.lumiera.org/debian/gdlmm' urlGDLmmDEB = 'http://lumiera.org/debian/' if not conf.CheckPkgConfig('gdl-3.0', verGDL): problems.append('GNOME Docking Library not found. We need at least GDL %s ' 'and suitable C++ ("mm")-bindings (GDLmm >=%s)' % (verGDL, verGDLmm)) if not conf.CheckPkgConfig('gdlmm-3.0', verGDLmm, alias='gdl'): problems.append('We need the C++ bindings for GDL by Fabien Parent: GDLmm >=%s ' - '(either from GNOME %s or use the debian package from %s)' % + '(either from %s or use the debian package from %s)' % (verGDLmm, urlGDLmm, urlGDLmmDEB)) - if not conf.CheckPkgConfig('librsvg-2.0', '2.30'): + if not conf.CheckPkgConfig('librsvg-2.0', '2.40'): problems.append('Need rsvg Library for rendering icons.') if not conf.CheckCHeader(['X11/Xutil.h', 'X11/Xlib.h'],'<>'): diff --git a/admin/scons/Setup.py b/admin/scons/Setup.py index ce97167af..d4a09fa12 100644 --- a/admin/scons/Setup.py +++ b/admin/scons/Setup.py @@ -57,8 +57,8 @@ def defineBuildEnvironment(): define locations in source and target tree, parse the commandline and pick up options """ - EnsureSConsVersion(2,0) - EnsurePythonVersion(2,6) + EnsureSConsVersion(4,0) + EnsurePythonVersion(3,10) Decider('content-timestamp') # detect changed files by timestamp, then do a MD5 buildVars = Variables([OPTCACHE, CUSTOPTFILE]) @@ -83,7 +83,7 @@ def defineBuildEnvironment(): appendVal(env,'OPTIMIZE', 'CCFLAGS', val=' -O3') appendVal(env,'DEBUG', 'CCFLAGS', val=' -ggdb') - # NOTE: could define optional copile features here.... + # NOTE: could define optional compile features here.... Options.prepareOptionsHelp(buildVars,env) buildVars.Save(OPTCACHE, env) diff --git a/doc/technical/build/BuildDependencies.txt b/doc/technical/build/BuildDependencies.txt index 38dfe9581..f841c1583 100644 --- a/doc/technical/build/BuildDependencies.txt +++ b/doc/technical/build/BuildDependencies.txt @@ -1,7 +1,7 @@ Build Dependencies ================== :Author: core-devs -:Date: 2/2020 +:Date: 11/2025 :toc: @@ -10,26 +10,52 @@ We try to get the best out of modern system programming techniques to reach a solid performance and good throughput. Lumiera shall scale with the provided Hardware, the more RAM and the more/faster CPU's you have the better. -Nevertheless lower end 32bit machines are supported too. +Nevertheless lower end 64bit machines are supported too. Secondary targets will be other free operating systems which offer a decent Posix API. Porting to other more or less similar platforms will be possible, if -- by coincidence -- Someone(TM) helps with porting. -Having said that -- for the time being, the core team won't spend much effort on porting. +Having said that -- for the time being, the core team won't spend much effort on porting, +be it to special hardware or some other popular OS. + Platform -------- -We develop and test on standard PC hardware, 32 and 64 bit. +We develop and test on standard PC hardware, 64 bit.footnote:[ + We attempt to write code mostly in a portable way, yet we have encountered + several aspects now where our solution effectively assumes 64bit layout -- + and thus the code might compile on 32bit, but then not perform as expected. + A notorious example are _hash values_, which are typed as `size_t` following + the C++ idiom. We now use a hash function that is clearly optimised for 64bit, + and we know that a 32bit hash would produce collisions on a regular base, while + our solution assumes that collisions can be ruled out effectively. This is just + one example, which shows that handling such aspects in a portable fashion, while + certainly possibly, requires a significant amount of design work and incurs + additional complexity. + For the time being, we are content to document such cases as tickets. +] It is intended to target other platforms running GNU/Linux eventually. -Lumiera expects a `standard' desktop installation running a XServer. +Lumiera expects a ``standard'' desktop installation running a XServer.footnote:[ + Wayland is ``just around the corner'' since 10 years now. Well, recently it + seems it is _really_ just around the corner. We are aware of the necessary + changes, which are not very complicated to implement (since we are using + GTK-3). However, as long as Wayland simply crashes or hands in our + everyday work setup with XFCE, we will not consider this topic + a priority. In the meantime, please report any problems + you encounter with Lumiera running on XWayland. +] Graphics:: - There are no special requirements for the graphic system. - Hardware acceleration will likely be added later through extensions, - but will remain strictly optional.footnote:[For the time being, we'll watch - the evolution in that area and might revisit that topic when there are more - compelling and widely supported solutions available] + There are no special requirements for the graphic system, other than + some GPU supported for common desktop display in the standard setup. + Hardware acceleration for video processing will likely be added later + through extensions, but will remain strictly optional.footnote:[ + For the time being, we'll watch the evolution in that area + and might revisit that topic when there are more compelling + and widely supported solutions available. Support for 32bit + floating point data formats is considered more important. + ] Disks:: No special requirements. Video editing requires decent disk speed though, @@ -42,6 +68,7 @@ Special Hardware:: * Specs and APIs must be open. * someone to do the actual interfacing and support needs to join the team + Compatibility ~~~~~~~~~~~~~ We try to keep our depdendencies close to Debian/stable and the most recent Ubuntu LTS. @@ -54,55 +81,101 @@ Languages and Tools * C / C++ - - a C99 / C++17 compatible compiler footnote:[in practice, we build using GCC and - occasionally we check using Clang] - - GCC *7* or Clang *6* should be fine footnote:[basically we try to use just the stock language. - On rare occasions in the past, we _did_ use some GCC extensions, like `typeof()`, but we care for - workarounds, in case this becomes a problem. Incidentally, `typeof()` is obsoleted by the new - C++ standard, which provides `decltype()` for this purpose.]. + - A C\+\+23 compatible compiler is required.footnote:[ + In practice, we build using GCC and occasionally we check using Clang. + Right now (7/2025) Clang has fallen behind regarding support of type dependent + name resolution in templates and does not even comply with C++20 in this respect. + We have dropped most usages of the `typename` keyword recently, and as long as + Clang can not cope with that, we have to postpone further tests with Clang. + ] + - GCC-**14** or better should be fine.footnote:[ + Basically we try to use just the stock language. + But we actually compile with the GNU extensions, i.e. `-std=gnu++23` / `-std=gnu99`. + And any language feature is used to the degree that it is available and stable + in this build environment. + ] * BOOST (listed below are the Debian package names) - - libboost-dev (at least *1.67*) - - libboost-program-options-dev + - libboost-dev (at least *1.83*) - libboost-program-options-dev * Script languages - - Python (*2.x*) might still be handy for build scripts.footnote:[SCons supports both Python 2.x - and Python 3.x transparently. Basically there is no reason to stick to Python 2.x -- just the standard - python is not yet switched on Debian/stable, and so we might miss out on some scripts.] + - Python (*3.10*) required for building (->SCons) - bash (some test scripts use bash specific extensions) Build Tools ~~~~~~~~~~~ -* Git -* SCons *2.0* footnote:[we build with SCons >= 3.0 since a long time. However, since the times of 2.0, - there are no major breaking improvements we rely on -- so chances are that the Build works fine with - older versions. In addition, we use some SCons plug-ins, which are all shipped in-tree (`admin/scons`)] +* https://www.scons.org/[SCons build system] v**4.8** footnote:[ + Unfortunately, SCons still sets the conceptual standard how a modern build system should be: + It is declarative, defines the _what_ and not the _how_ and uses build scripts written in + a clean and modern language (Python). + Autotools should be considered legacy, and CMake turned out to be rather disappointing and + lacks adequate conceptual grounding. Meson has a somewhat more modern appeal, yet seems to + require us to do much more work to get even remotely to that level of clarity and flexibility + which we enjoy every day when working with SCons. + + We are aware of the shortcomings of SCons in practice however, notably that it is not widely + known and thus requires additional learning effort, and that it could become prohibitively + slow on very large projects. At the current project size, the delay on incremental builds + does not really seem relevant in practice, given that C++ compilation as such is slow anyway. + We are not aware of using any notable features of SCons beyond v2.0, and we use some SCons + plug-ins, which are all shipped in-tree (directory 'admin/scons')] * pkg-config -* Doxygen +* Doxygen (optional) +* Asciidoc (optional) +* Git -> https://git.lumiera.org/?p=LUMIERA;a=summary[git://git.lumiera.org/LUMIERA] + footnote:[ + _Ichthyo_ maintains a repo at https://github.com/Ichthyostega/Lumiera/[Github ^~Ichthyostega/Lumiera^] + ] -We maintain a link:/documentation/technical/infra/debianDepot.html[Debian/Ubuntu package] (relying on debhelper, CDBS, git-buildpackage) +💡 We maintain a link:{ldoc}/technical/infra/debianDepot.html[Debian/Ubuntu package] (based on `git-buildpackage`) Libraries ~~~~~~~~~ -* BOOST -* link:http://nobug.pipapo.org/[NoBug] +* https://www.boost.org/[Boost libraries] +* https://nobug.pipapo.org/[NoBug library] * https://github.com/bplaum/gavl[GAVL] (for raw media support) -* ALSA: libasound2-dev -* for the GUI: (*GTK-3*) gtkmm-3.0 gdlmm-3.0 glibmm-2.4 cairomm-1.0 xv - - libgtkmm-3.0-dev - - libcairomm-1.0-dev - - libglibmm-2.4-dev, requiring at least glib2.0 (2.40 or better) and gthread-2.0 - - libxv-dev footnote:[for the XV viewer widget `gui/output/xvdisplayer.cpp` - -- currently obsolete as of [yellow-background]#5/2015#][yellow-background]#TODO 5/2015# and X-lib - - librsvg-2.0 and librsvg2-dev for rendering Icons - - libgdl-3 (3.12 or better) through libgdlmm-3 -- the »Gnome Docking Library«footnote:[GDL isn't directly related to GNOME any more. - We contributed to the improvement of this library in the past. These improvements went upstream - with GDL-2.27. At times, we used to ship our own GDL package. Right now, a recent upstream version - together with the corresponding *mm-bindings will do. We provide a debian package for the latter, - until they will be available in the official Debian/Ubuntu/Mint repos. But we don't have any - special requirements on these `gdlmm` bindings.] +* https://www.alsa-project.org/[ALSA (libasound2-dev)] +* for the GUI: (*GTK-3*) gtkmm, glibmm-2.4, cairomm-1, gdlmm-3, Xv + - libgtkmm-3.0-dev (`>=3.20`) + - libglibmm-2.4-dev (`>= 2.66`), requiring at least glib2.0 (`>=2.80`) + - libcairomm-1.0-dev (`>= 1.14`) + - librsvg2-dev (`>=2.40`) for rendering Icons + - libxv-dev footnote:[ + For the time being, this is a placeholder and fallback to integrate + any technology for displaying video frames on the dektop. It is now used in the + XV viewer widget 'stage/output/xv-displayer.hpp|cpp' -- currently expected + to be obsolete soon, but it is yet [yellow-background]#undecided as of 11/2025# + what we use as starting point for video output from the Lumiera Render Engine. + XV might be retained as a fall-back solution, the libraries GLX or EGL might be used... + ] + and X-lib ^[yellow-background]#TODO 11/2025#^ + - libgdl-3-dev (`>= 3.40`) through libgdlmm-3 -- the »Gnome Docking Library«footnote:[ + https://gitlab.gnome.org/Archive/gdl.git[lib GDL] isn't directly related to GNOME any more. + We use this library for docking panels in the GUI with GTK-3. This solution was maintained + for some time by the »Anjuta« project -- we also contributed to the improvement of this library + in the past, and these improvements went upstream with GDL-2.27. Unfortunately, GDL was abandoned + meanwhile. and we do not see a clear pathway for the future here, short of upgrading to GTK-4, + which is possible, but would require some considerable effort. As of 2025, GDL is still usable, + but no longer available through the standard distribution channels. + + We provide a Git repository at our Website for + https://git.lumiera.org/?p=debian/gdl;a=summary[libGDL (3.40) +git://git.lumiera.org/debian/gdl+] + and the + https://git.lumiera.org/?p=debian/gdlmm;a=summary[GDL C++ bindings (3.7.3) +git://git.lumiera.org/debian/gdlmm+] + and we maintain custom Debian packages for both in our + link:/debian/[Debian DEB depot]. + ] +'''' +.Documentation and Resources +[TIP] +-- +* Tutorial link:{ldoc}/user/tutorials/building.html[Building Lumiera from source] +* Tutorial link:{ldoc}/user/tutorials/DebianBuilding.html[Building the »Debian Way«] +* About the link:{ldoc}/technical/build/LumieraDebianPackage.html[Lumiera Debian Package] +* About the link:{ldoc}/technical/build/SCons.html[SCons Build-System of Lumiera] +* About the link:{ldoc}/technical/code/index.html[Code Base Organisation] +* link:/debian/[Lumiera Debian DEB depot] +-- diff --git a/doc/technical/build/SCons.txt b/doc/technical/build/SCons.txt index e4341cb11..cd4acb7e2 100644 --- a/doc/technical/build/SCons.txt +++ b/doc/technical/build/SCons.txt @@ -18,7 +18,7 @@ Synopsis -------- [cols=">, all cores +| just build Lumiera: | scons -j# | # ≔ number of CPUs | build + run Tests: | scons -j# check | -> see 'target/,testlog' | development build: | scons -j# testcode | -> `target/test-suite ` | install: | scons -j# install | installs below '/usr/local/', ⚠ sudo diff --git a/doc/user/tutorials/DebianBuilding.txt b/doc/user/tutorials/DebianBuilding.txt index 1af8aa542..d0f461fba 100644 --- a/doc/user/tutorials/DebianBuilding.txt +++ b/doc/user/tutorials/DebianBuilding.txt @@ -63,7 +63,7 @@ the build. You need to _install_ these packages then using the basic Debian pack manager `dpkg` + ---- -sudo dpkg -i libnobug2_201008.1-1_i386.deb nobug-dev_201008.1-1_i386.deb +sudo dpkg -i libnobug2_201008.1-4~trixie_amd64.deb nobug-dev_201008.1-4~trixie_amd64.deb ---- + of course, the package names, versions and architecture will vary, depending on your diff --git a/doc/user/tutorials/building.txt b/doc/user/tutorials/building.txt index a5c390c0d..5323570eb 100644 --- a/doc/user/tutorials/building.txt +++ b/doc/user/tutorials/building.txt @@ -1,6 +1,6 @@ Building Lumiera from source ============================ -:Date: 2020 +:Date: 2025 :toc: At the moment you can build Lumiera, start the standard Lumiera GUI and run the @@ -46,33 +46,33 @@ authoritative information about the build dependencies is encoded into the link:{ldoc}/technical/build/SCons.html[build system]. Thus, when the build system aborts, indicating that a never version of some library is required, then usually the build system is right...] -More specifically, you'll need the GNU C/C\++ compiler with C++17 support (Version >= 7) +More specifically, you'll need the GNU C/C\++ compiler with C++23 support (Version >= 14) in addition to the following tools and libraries: * https://git-scm.com/[Git] (version management system) * https://www.scons.org/[SCons build system] * https://www.boost.org/[Boost libraries] * https://github.com/bplaum/gavl[GAVL library] - * https://nobug.pipapo.org/[NoBug] (see below) - * Lumiera source code + * https://nobug.pipapo.org/[NoBug] ~([purple]#⚠ see below#)~ + * Lumiera https://git.lumiera.org/?p=LUMIERA;a=summary[source code] The GUI depends on the following: * https://gtkmm.gnome.org/en/[gtkmm] * https://cgit.freedesktop.org/xorg/lib/libXv[libXv] * https://wiki.gnome.org/Projects/LibRsvg[lib rSVG] - * https://gitlab.gnome.org/Archive/gdl.git[lib GDL] + * https://gitlab.gnome.org/Archive/gdl.git[lib GDL] ~([purple]#⚠ see below#)~ TIP: Generally speaking, when you want to build software, you'll need the _development_ version of the packages that contain the headers and pre-built libraries to link against. These packages are usually named `-devel` or `-dev`. -For Debian based systems, e.g. Mint, Ubuntu..., you can install these packages as follows: +For Debian based systems, e.g. Ubuntu, Mint... you can install these packages as follows: ------------------------------------------------------------------------------------- -sudo apt-get install build-essential scons git-core valgrind intltool \ -libboost-dev libboost-program-options-dev \ -libgavl-dev libgtkmm-3.0-dev libgdl-3-dev librsvg2-dev libxv-dev +sudo apt-get install build-essential g++ git pkgconf scons intltool \ +libboost-dev libboost-program-options-dev libasound2-dev libgavl-dev \ +libgtkmm-3.0-dev librsvg2-dev libxv-dev ------------------------------------------------------------------------------------- @@ -91,17 +91,23 @@ Lumiera Specific Libraries Now that you have your basic build environment prepared, the next step is to care for some special libraries required by Lumiera that are not directly part of the Lumiera project itself, but aren't readily available through the usual package -manager of the common distributions either. footnote:[we maintain our own Debian -package depot at Lumiera.org and provide binary Debian packages for a range of -distributions; yet this tutorial strives at showing the basic and generic method -for building. Thus we'll show you here how to build these libraries from source -yourself] Thus, we'll have to get the source code for these support libraries, +manager of the common distributions either.footnote:[ + We maintain our own + link:/debian/[Debian package depot at Lumiera.org] + and provide binary Debian packages for a range of distributions; + yet this tutorial strives at showing the basic and generic method for building. + Thus we'll show you here how to build these libraries from source yourself -- + however, in many cases it can be more convenient to use the DEB packages + we provide, if applicable, for these extra library dependencies of Lumiera + and just care for building the Lumiera main tree on your system. +] +Thus, we'll have to get the source code for these support libraries, build and install them before we're able to compile Lumiera. WARNING: Note that the following procedures will try to install files into your -base system below `/usr/local`. + -To do so, you'll need administrative permission for the machine you're working -on. These additions might interfere with other libraries installed by your +base system below '/usr/local'. + +To do so, you'll need [red]#administrative permission# for the machine you're +working on. These additions might interfere with other libraries installed by your package manager (if you get into trouble updating your system later on, you might have to manually remove these libraries). @@ -208,24 +214,31 @@ footnote:[more options for building with scons can be found via: `scons -h` ] ----------------- git clone git://git.lumiera.org/LUMIERA cd LUMIERA -scons +scons -j# ----------------- -maybe build and run the test suite by issuing `scons check` - The build process will take some time, so sit back and relax. +You can use for `#` (at least) the number of cores available on your system +to speed up the build -- but it will take several minutes even for a debug +build and significantly more for an optimised release build (-> see `scons -h`) + +And if you feel like waiting even more, you might build and run the test suite +by issuing `scons -j# check`... + NOTE: you do not need to _install_ Lumiera. It will find all files it requires relative to the directory structure it generates, which is freely relocatable -as a whole. Just invoke the +target/lumiera+ executable. The current +as a whole. Just invoke the 'target/lumiera' executable. The current working directory is not particularly relevant. After the build has finished successfully, you should be able to start Lumiera. -Currently, this will bring up the GUI, _without any further functionality_ (!) +Currently, this will bring up the GUI, _without much further functionality_ (!) You should see something like this: -image:/images/lumiera_gui_small.png[Current Lumiera GUI Screenshot] +image:{imgg}/lumiera20250823.png["Current Lumiera GUI Screenshot",width=650] + +-> 💡 see link:{ldoc}/user/manual.html#_ui_experiments[here] for some demo features available... What's next? diff --git a/doc/user/tutorials/contributing.txt b/doc/user/tutorials/contributing.txt index a647e7fcf..440733825 100644 --- a/doc/user/tutorials/contributing.txt +++ b/doc/user/tutorials/contributing.txt @@ -1,7 +1,7 @@ Contributing to Lumiera ======================= :Author: Benny -:Date: Oct 2013 +:Date: Oct 2013 · Nov 2025 :toc: @@ -86,12 +86,12 @@ Lumiera. These additional packages are of two kinds: Packages normally available with your distribution:: for a Debian based system (including Mint, Ubuntu and similar flavours), - you should be able to install the necessary dependencies with the command + you should be able to install the necessary dependencies with the command... + ------------------------------------------------------------------------------------- -sudo apt-get install build-essential scons git-core valgrind intltool \ -libboost-dev libboost-program-options-dev \ -libgavl-dev libgtkmm-3.0-dev libgdl-3-dev librsvg2-dev libxv-dev +sudo apt-get install build-essential g++ git pkgconf scons intltool \ +libboost-dev libboost-program-options-dev libasound2-dev libgavl-dev \ +libgtkmm-3.0-dev librsvg2-dev libxv-dev ------------------------------------------------------------------------------------- Packages not normally part of your distribution:: there are two packages most likely not available with your operating system @@ -101,7 +101,7 @@ Packages not normally part of your distribution:: - *NoBug* -- a diagnostics library + ------------------------------------------------------------ -git clone git://git.pipapo.org/nobug +git clone git://git.lumiera.org/debian/nobug cd nobug autoreconf -i mkdir build && cd build @@ -109,22 +109,43 @@ mkdir build && cd build make sudo make install ------------------------------------------------------------ - - **mm**-bindings for *GDL* -- a window docking library footnote:[GDL itself _is_ - available through the standard package manager, in a version compatible to GTK-3. - What is not yet available are the corresponding C++ bindings `gdlmm-3`] + - the *libGDL* with **mm**-bindings -- a window docking library footnote:[ + GDL is compatible with GTK-3 and was available through the standard package manager, + but was orphaned in 2021. Since it is currently a prerequisite for building Lumiera, + we maintain a clone of the original repository and a Debian package on Lumiera.org. + This is relevant both for + https://git.lumiera.org/?p=debian/gdl;a=summary[libGDL (3.40) +git://git.lumiera.org/debian/gdl+] + and the + https://git.lumiera.org/?p=debian/gdlmm;a=summary[GDL C++ bindings (3.7.3) +git://git.lumiera.org/debian/gdlmm+]. + ] + + * first you have to build libGTL itself... + ------------------------------------------------------------ -git clone git://git.lumiera.org/debian/gdlmm -cd gdlmm -./configure +git clone git://git.lumiera.org/debian/gdl +cd gdl +git checkout master +./autogen.sh make sudo make install ------------------------------------------------------------ + * then followed by building the C++ bindings... ++ +------------------------------------------------------------ +git clone git://git.lumiera.org/debian/gdlmm +cd gdlmm +git checkout master +./autogen.sh +make +sudo make install +------------------------------------------------------------ + + Start the Lumiera build process:: ------------------------------------------------------------ cd LUMIERA -scons +scons -j# ------------------------------------------------------------ If Lumiera is built correctly on your system, you should be able to shoot up @@ -197,7 +218,7 @@ Finally you can *push* your changes to the Lumiera server on the 'mob' repository: ------------------------------------------------------------ -$ git push git://git.lumiera.org/lumiera/mob master:refs/heads/YOURNAME +$ git push git://git.lumiera.org/lumiera/mob master:YOURNAME ------------------------------------------------------------ This creates a new branch +YOURNAME+ on the mob repository. diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index 9fe5ec78c..c7f392f3f 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -166815,8 +166815,8 @@ that situation will improve in forseeable future. - - + + @@ -170170,9 +170170,9 @@ that situation will improve in forseeable future. - - - + + + @@ -170690,22 +170690,23 @@ that situation will improve in forseeable future. - + - - - + + + - - + + + - - + + @@ -170715,10 +170716,15 @@ that situation will improve in forseeable future. + - - + + + + + + @@ -171094,20 +171100,51 @@ actively maintained upstream. Please remove gdl from Debian. - - - + + + + + + - - - + + + + + + + + + +

+ Das betrifft auch das Thema »Video-Output«, zu dem Benny und ich einen Vortrag auf der FrOSCon25 gehalten haben. In dem Zusammenhang haben wir uns Basiskenntnisse in OpenGL und Shader-Programmierung angeeignet, aber beschlossen, das Thema vorerst noch nicht zu priorisieren — für die Integration von Lumiera genügt es wenn »irgendwie« Video ausgegeben werden kann.... +

+ + - + + + + +

+ ...rückt jetzt immer näher, in viele Distributionen wird er derzeit reingedrückt; für mich selber kommt Wayland aber erst in Frage, wenn er auf XFCE stabil läuft und mein »pragmatisches Farbmanagement« dadurch nicht gefärdet wird. Vermutlich bedeutet das, daß ich dazu erst mal mich von meiner UrUrUralten Grafikkarte trennen muß... (die sowiso nur noch für Debian/Trixie ein letztes Mal mit dem Tesla-Treiber unterstützt wurde). Haha, ich arbeite immer noch zufrieden und glücklich mit Hardware von 2011, das soll mir erst mal jemand nachmachen +

+ + + + + + + + + + + @@ -171599,7 +171636,7 @@ actively maintained upstream. Please remove gdl from Debian. - + @@ -171983,9 +172020,9 @@ Since then others have made contributions, see the log for the history. - - - + + + @@ -172014,9 +172051,9 @@ Since then others have made contributions, see the log for the history. - - - + + + @@ -172071,7 +172108,7 @@ Since then others have made contributions, see the log for the history. - + @@ -172292,7 +172329,7 @@ Since then others have made contributions, see the log for the history. - + @@ -172320,6 +172357,26 @@ Since then others have made contributions, see the log for the history. + + + + +

+ Oh weh! +

+

+ Hätte ich das Thema doch bloß nicht angefaßt ... das war jetzt mehr als ein Tag ekelhafte Debugging-Arbeit, und ich hab nun Interna von SCons gesehen, die ich lieber nicht wissen würde.... +

+

+ +

+

+ Meine Einschätzung bleibt allerdings trotzdem, daß SCons konzeptionell  eines der modernsten Buildsysteme ist, das ich kenne, und das einzige unter Linux geläufige Buildsystem, das auch nur anähernd zeitgemäß ist. Auch wenn die Implementierung dann sowohl »pythonisch«, alsauch „hemdsärmelig“ ist..... +

+ + + + @@ -172644,7 +172701,7 @@ Since then others have made contributions, see the log for the history. - + @@ -172664,8 +172721,8 @@ Since then others have made contributions, see the log for the history. - - + + @@ -178143,9 +178200,9 @@ Since then others have made contributions, see the log for the history. - - - + + + @@ -178476,22 +178533,23 @@ Since then others have made contributions, see the log for the history. - - - + + + - + - - - - + + + + + @@ -178510,7 +178568,7 @@ Since then others have made contributions, see the log for the history. - + @@ -178519,8 +178577,9 @@ Since then others have made contributions, see the log for the history. + - + @@ -178529,22 +178588,123 @@ Since then others have made contributions, see the log for the history. - - - - - - + + + + + + +

+ das ist derzeit tatsächlich verbindlich ... und auch relativ knapp so, weshalb es im Buildsystem gecheckt werden sollte +

+ + + + + + + +

+ ...im Grunde ist das gegen den Basis-Kontrakt, daß man lediglich »einen Compiler« verlangt... +

+ + + - + + - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ Das berücksichtigt auch Ubuntu-Noble(24.04), ist aber derzeit auch genau der Level, der in Debian-Trixie standardmäßig zum Einsatz kommt +

+ + + + + + + + + + + + + + + + + + + + + +

+ ist keine direkte Dependency mehr +

+ + + + + + + + + + + + + + + + + + + + + + + + + @@ -178561,25 +178721,34 @@ Since then others have made contributions, see the log for the history. - - + + - - +

- ...naja, nicht wirklich, denn dazu müßte ich mal die ganze SCons-Doku durhclesen, um zu sehen, was man modernisieren könnte. Aber da ich nun nur noch mit entsprechend neuerer Software arbeite, ist es auch nicht mehr angemessen, eine niedrigere Version zu deklarieren, da ich nicht merke, wenn ich neuere Feature verwende, die irgendwo im Internet beschrieben sind. + explizite Wahl, wegen Ubuntu/Noble +

+ + + + + + + +

+ ...naja, nicht wirklich, denn dazu müßte ich mal die ganze SCons-Doku durhclesen, um zu sehen, was man modernisieren könnte. Aber da ich nun nur noch mit entsprechend neuerer Software arbeite, ist es auch nicht mehr angemessen, eine niedrigere Version zu deklarieren, da ich nicht merke, wenn ich neuere Feature verwende, die irgendwo im Internet beschrieben sind. Konkret bin ich jetzt auf SCons 4.8 (habe 4.10 Features explizit noch nicht verwenden können). Allerdings ist Ubuntu-Noble erst auf 4.5 (hoffen wir mal daß das alles gut geht...)

- + - + @@ -178703,9 +178872,18 @@ Since then others have made contributions, see the log for the history. - + + + + +

+ Lifecycle/Start-up ist immer noch nicht failsafe ⟶ auf später vertagt, da es zusätzlich verkompliziert ist durch das Design des Subsystem-Runners, das eine zusätzliche Fehlerbehandlung jenseits der Event-Loop schwierig macht; und ich bin mit diesem Design ohnehin nicht zufrieden, betrachte es aber nicht als ein dringendes Problem +

+ + + @@ -179036,7 +179214,7 @@ env.Chmod(installed[0], 0o644) - + @@ -179048,7 +179226,7 @@ env.Chmod(installed[0], 0o644) - + @@ -179197,7 +179375,7 @@ env.Chmod(installed[0], 0o644) - + @@ -179239,7 +179417,7 @@ env.Chmod(installed[0], 0o644) - + @@ -179431,7 +179609,7 @@ env.Chmod(installed[0], 0o644) - + @@ -182176,6 +182354,7 @@ env.Command('out.bin', 'in.bin', my_action) +