Clone from the Lumiera Master-Repo (as Test for Forgejo)
https://git.lumiera.org/
Ichthyostega
d24e025de2
Many years ago, I integrated the IconSvgRenderer (written by Joel Holdsworth) directly into the SCons build by means of a custom builder with an ''emitter function''. The build as such works fine and automatically determines which icons can be generated from a given SVG source. However, those SVG icons tend to be rebuilt very frequently, even while none of the SVG sources has changed. Basically this was more of an annoyance, since we have now about 15 icons and the rendering is really fast ... it is just ugly, especially on incremental builds (and it could become a problem once we have a massive amount of graphics to process. So I took the opportunity to take close look now, since I am doing uninspiring clean-up work since several weeks now. But that problem turned out to be quite insidious and hard to spot. First, AI set me off into a completely wrong angle, since it is ''not'' caused by a missing string representation of the custom Action class. However, from there I went to watching the target checks with the debugger, and this eventually got me to realise, that SCons mistakenly detects a change in the Executor / the Action class. The root cause is, that we invoke Python code from an external Module, IconSvgRenderer.py, and this is »materialised« by SCons automatically into a string representation, which includes memory addresses of functions in that module. And that yields a signature, that is, quite obviously, not stable, even while you end up sometimes with loading the code to the same memory location. As a solution / workaround, we now subclass the standard implementation from SCons and override the signature function; instead of fingerprinting the binary code, we just compute a MD5 over the python source file, which can be easily achieved with the help of the File-Node from SCons. Essential resources: https://scons.org/doc/4.8.0/HTML/scons-user.html#chap-builders-writing ...and the Reference / Manpage of SCons https://scons.org/doc/4.8.0/HTML/scons-man.html#action_objects SCons/Action.py SCons/Node/__init__.py |
||
|---|---|---|
| admin | ||
| data | ||
| doc | ||
| po | ||
| research | ||
| src | ||
| target | ||
| tests | ||
| uml | ||
| wiki | ||
| .gitignore | ||
| AUTHORS | ||
| COPYING | ||
| DIR_INFO | ||
| LICENSE | ||
| NEWS | ||
| README | ||
| SConstruct | ||
Lumiera -- the video NLE for Linux ================================== Version: 0.pre.04~rc.1 :Date: 11/2025 ************************************************************* Lumiera is a non-linear video editing and compositing tool. The Application will allow to edit footage using common multimedia formats and audio/video stream codecs. Lumiera features nondestructive editing, compositing tools, a selection of effects plugins, processing in RGB, YUV and RGB-float colour models and the ability to mix media with differing sizes and framerates. Lumiera is especially well suited for large and elaborate professional editing tasks with lots of material, several scenes, nested sequences, colour grading, 3D support, full fledged sound montage and multiple edit versions prepared in parallel. NOTE: as of 11/2025, Lumiera is in early development stage; it is not usable yet. The above describes the Lumiera project vision, the implementation of which will require many more years. Visit https://Lumiera.org and join the mailing list when interested in Lumiera planning and development. **************************************************************** Lumiera pre-Alpha Versions -------------------------- .This source tree doesn't contain a working video editing application yet. Rather, it contains the framework and technology core of the envisioned Application »Lumiera«. What we attempt to build here is innovative, and we must engage in a series of integration steps to search for suitable pathways towards our envisaged architecture. Since 2024, the integration of the Render Engine takes centre stage, in an effort to establish a steady state realtime processing and display pipeline, still relying on generated video data rather than using a library to read and playback a video file. - https://Lumiera.org/documentation/design/governance/integration.html[Integration steps] - See also https://issues.lumiera.org/roadmap[Project roadmap] Build Requirements ------------------ For building Lumiera, you'll need: * C++23 compiler GCC >=14 (Clang fails atm) * 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://www.alsa-project.org/[ALSA (libasound2-dev)] * https://nobug.pipapo.org/[NoBug library] * https://gtkmm.gnome.org/en/[gtkmm] * https://cgit.freedesktop.org/xorg/lib/libXv[libXv] * https://wiki.gnome.org/Projects/LibRsvg[lib rSVG] * https://git.lumiera.org/?p=debian/gdl;a=summary[lib GDL] * https://git.lumiera.org/?p=debian/gdlmm;a=summary[GDL-mm bindings] Further information: * Online documentation at https://Lumiera.org/download.html[Build and install]. * Documentation is also available in-tree in 'doc/user/tutorials/building.txt' * Source code can be retrieved with `git clone git://git.lumiera.org/LUMIERA` Debian Package -------------- Hermann Vosseler (aka Ichthyo) maintains a *Debian* packaging of the source tree - the package definition can be pulled from `git://git.lumiera.org/debian/lumiera/` - the package can be built by `git-buildpackage`