Starting with ''preview release'' `v0.pre.04`, branch and version tags
will be handled in accordance to the **Git-flow** naming scheme.
Notably this implies that from now on the version in-tree will indicate
the ''next expected release,'' adorned by a suffix to mark the preview.
To accommodate this transition to Git-flow
- the new branch `integration` will be introduced
- the version number will once (and the last time for this release)
be adjusted ''before'' forking the release branch
- branch `master` will transition to reflect the latest released state
- several existing branches will be discontinued, notably
`gui`, `steam`, `vault`, `release`, `play`
The Lumiera »Reference Platform« is now upgraded to Debian/Buster, which provides GCC-14 and Clang-20.
Thus the compiler support for C++20 language features seems solid enough, and C++23,
while still in ''experimental stage'' can be seen as a complement and addendum.
This changeset
* upgrades the compile switches for the build system
* provides all the necessary adjustments to keep the code base compilable
Notable changes:
* λ-capture by value now requires explicit qualification how to handle `this`
* comparison operators are now handled transparently by the core language,
largely obsoleting boost::operators. This change incurs several changes
to implicit handling rules and causes lots of ambiguities — which typically
pinpoint some long standing design issues, especially related to MObjects
and the ''time entities''. Most tweaks done here can be ''considered preliminary''
* unfortunately the upgraded standard ''fails'' to handle **tuple-like** entities
in a satisfactory way — rather an ''exposition-only'' concept is introduced,
which applies solely to some containers from the STL, thereby breaking some
very crucial code in the render entities, which was built upon the notion of
''tuple-like'' entities and the ''tuple protocol''. The solution is to
abandon the STL in this respect and **provide an alternative implementation**
of the `apply` function and related elements.
Indeed — this change set is kind of sad.
Because I still admire the design of the GAVL library,
and would love to use it for processing of raw video.
However, up to now, we never got to the point of actually
doing so. For the future, I am not sure if there remains
room to rely on lib-GAVL, since FFmpeg roughly covers
a similar ground (and a lot beyond that). And providing
a plug-in for FFmpeg is unavoidable, practically speaking.
So I still retain the nominal dependency on lib-GAVL
in the Build system (since it is still packaged in Debian).
But it is pointless to rely on this library just for an
external type-def `gavl_time_t`. We owe much to this
inspiration, but it can be expected that we'll wrap
these raw time-values into a dedicated marker type
soon, and we certainly won't be exposing any C-style
interface for time calculations in future, since
we do not want anyone to side-step the Lumiera
time handling framework in favour of working
„just with plain numbers“
NOTE: lib-GAVL hompage has moved to Github:
https://github.com/bplaum/gavl
Since C++17 we can use the std::filesystem instead (and we ''do use it'' indeed)
- relocate the `/lib/file.hpp` header
- adapt the self-discovery of the executable to using std::filesystem
Furthermore, some recherche regarding XVideo and Video Output
A long time ago, we grabbed this plug-in from the Scons Wiki.
The latest version from 2022-07-31 was upgraded to Python-3
Note: this merge retains our reformatted copyright header
and the addition of a ",doxylog" file in the target dir
Actually, the Lumiera project picked an early version of this tool in August 2008.
See the commits:
6d5cf0e6429643f46cc8
This subtree add/merge commit brings in a consolidated history of the Scons Doxygen code
from the scons-contrib repository, combined with the old Mercurial history.
We need a current version of this tool which has been ported to Python-3
BuilderDoxygen and BuilderGCH are external plug-ins,
not developed in this project and probably unmaintained.
TODO: decide how to fix or replace them...
ListType not supported in types.py in Python3
Why do we require ListType?
To do something like
if type(item) is ListType:
....
But types.py does not have ListType anymore
A solution could be
if isinstance(item, list):
TODO: WIP-remove these comments and fix the code or replace BuilderGCH
The build system Scons switched from using Python 2.7 to using
Python 3.x, so the build breaks on, for example, Debian Bullseye.
As a first step use `ato3` to convert Python scripts from 2 to 3.
* Lumiera source code always was copyrighted by individual contributors
* there is no entity "Lumiera.org" which holds any copyrights
* Lumiera source code is provided under the GPL Version 2+
== Explanations ==
Lumiera as a whole is distributed under Copyleft, GNU General Public License Version 2 or above.
For this to become legally effective, the ''File COPYING in the root directory is sufficient.''
The licensing header in each file is not strictly necessary, yet considered good practice;
attaching a licence notice increases the likeliness that this information is retained
in case someone extracts individual code files. However, it is not by the presence of some
text, that legally binding licensing terms become effective; rather the fact matters that a
given piece of code was provably copyrighted and published under a license. Even reformatting
the code, renaming some variables or deleting parts of the code will not alter this legal
situation, but rather creates a derivative work, which is likewise covered by the GPL!
The most relevant information in the file header is the notice regarding the
time of the first individual copyright claim. By virtue of this initial copyright,
the first author is entitled to choose the terms of licensing. All further
modifications are permitted and covered by the License. The specific wording
or format of the copyright header is not legally relevant, as long as the
intention to publish under the GPL remains clear. The extended wording was
based on a recommendation by the FSF. It can be shortened, because the full terms
of the license are provided alongside the distribution, in the file COPYING.
- reformat in Lumieara-GNU style
- use the Lumiera exceptions
- use Lumiera format-string frontend
- use lib/util
NOTE: I am the original author of the code introduced here,
and thus I can re-license it under GPL 2+
Mostly, std::regexp can be used as a drop-in replacement.
Note: unfortunately ECMA regexps do not support lookbehind assertions.
This lookbehind is necesary here because we want to allow parsing values
from strings with additional content, which means we need explicitly to
exclude mismatches due to invalid syntax.
We can work around that issue like "either line start, or *not* one of these characters.
Alternatively we could consider to make the match more rigid,
i.e we would require the string to conain *only* the timecode spec to be parsed.
the new structure causes them now to be installed into $TARGET/stage
which is simply not what I want. I still consider $TARGET/gui the better choice,
since an administrator or packager is not aware of our layer namings.
The existing solution was half baked anyway, it did not really replicate the source tree.
On the other hand, I want to retain the location of the CSS files within the GUI tree,
since I consider it a good practice, to keep "code-like" resources with the actual code,
and not far away in some arcane "data" directory.
No I've noticed, that the env.GuiResource() function is only used once, for this very task.
So, for the time being, we can keep it simple and deditaced to that task, i.e
we pick up all CSS files we find and install it into a single target directory.
NOTE: this issue has brought to my attention two further, completely unrelated issues
* Ticket #1192 (Lumiera hangs on failed GUI start)
* The ProcDispatcher does an idle wait, due to an error in timed-wait implementation
This warning is only relevant when object files compile with and without
C++17 language level are to be linked into a single executable; starting
with C++17, new style 'noexcept' specifications will become part of the
function signature and thus part of the mangled function name. Linkiing
mixed object files might fail in such a situation.
Obviously this warning is not relevant for us; moreover we plan to
upgrade to C++17 soon
Explanation: sigC++ was already linked as transitive dependency
from gtkmm, since it is used for the "signal-slot" system wihin GTK.
But now we want to use sigC++ itself from our generic UI-Backbone,
so we need to pick up the additional compiler and linker flags
and use them when building the relevant parts of both the application
and the test suite
For Lumiera, what we actually need is a GTK-3 compliant libGDL.
Since Mint Rafaela (17.2) has only the rather old version 3.8, we lower
the dependency requirements. Not sure if this causes any problems...
lumiera (0.pre.03-1~rafaela) Lumiera-rafaela; urgency=low
* Rebuild for Mint 17.2 (Rafaela)
* lower requirements on libGDL to 3.8 (a bit outdated, but should do)
* use custom installed gcc-4.9 and libstdc++ 4.9 for building,
since Mint 17.2 has only gcc-4.8 and we need full c++14 compliance
Hint: use add-apt-repository ppa:ubuntu-toolchain-r/test
Author: Hermann Vosseler <deb@ichthyostega.de>
NOTE: we have the policy to always support current Debian/stable
amd at least one Ubuntu LTS release, unless hard dependency problems prevent that.
Currently, Ubuntu/Trusty is already a bit dated, but the only problematic dependency
could be libboost (1.54 in Trusty, 1.55 in Jessie).
GCC-4.8 can be replaced by GCC-4.9 in Trusty without problems
It is always a bit tricky to find out the precise lower boundary,
so we try to upgrade these requirements as our platform progresses.
For now we have used the level available on Ubuntu/Trusty to set
the lower constraints for most libraries
...this is proposed by debian; lets see how this turns out
We could also add -fstack-protector-strong, but I prefer
to set this in the package definition
...this will be the third preview release
Lumiera is still in pre-alpha stage, and thus
there are no proper releases, just preview snapshots.
Again this version will be built and packaged
on several supported Linux platforms
This means we have rather tight compiler requirements now.
Beyond that, we expect no serious impact; the most notable
C++14 feature we're likely to use soon is type inference
on lambda arguments.
For the Gnome Docking Library, a recent official version will do.
For the mm-bindings by Fabien Parent we maintain our own debian package
at Lumiera.org/debian (there is no official debian package yet)
This is a somewhat intricate problem. As long as we linked with --no-as-needed,
these problems could not manifest themselves, since all dependencies are spotted
correctly by SCons and thus added as direct children of the executable.
But when we switch to --as-needed linking, the linker will omit some of
the dependencies given from the build system, when the code to be linked
doesn't call directly into these dependencies. But of course dynamic modules
may depend on each other, and indeed, the Lumiera libs do so. Thus
the linker may omit the dependency to liblumierasupport, and just add
a dependency to, say liblumierabackend. But the backend in turn
depends on the support library.
Now the problem is, that when resolving several steps deep into such
a dependency chain, our special relative path resolution scheme fails.
The fix is to give each lumiera module itself another relative path
resolution spec, which overrides at that point the root spec given
for the executable. Thus, we define
- for the executable: "search at $ORIGIN/modules"
- for the modules: "search at $ORIGIN/../modules"
This accounts for the fact, that a module, which is the Origin
for a transitive resolution step, already sits in a subdirectory
below the executable; thus step one level up and devle down into
the hard wired modules directory. Alternatively, we could also
use just "search at $ORIGIN" (i.e. in the same directory).
But assuming that in future we'll roll several core plugins,
which also count as "Lumiera modules", the scheme defined here
is more flexible, since it allows to place those core plugins
into sibling directories.
we still don't check for the precise boost version number in the
SCons configuration. We might do so in future, but for now our
policy is that precise version dependency checking is the business
of the packager (i.e. the debian package). The SCons build just
has to ensure the absolute necessary baseline
Why GNU extensions? They where on by default previously,
so we're changing nothing besides the C++ standard level.
AFAIK, we're using a GNU extension at one place, and this
could be replaced by 'decltype' now.
This improves sane library dependencies, as mandated
by debian policy. Some of the librt functions are in such
wide use, that we'd get them through transitive dependencies
anyway. But linking explicitly against a function adds the
DT_NEEDED for this library to our build artefacts. This is
correct, since we're actually using these functions ourselves,
making them into direct dependencies.
The recommendation is to use the link flag --no-undefined
and to fed *all* dependencies to the respective link step.
This changeset enables this strict linking of dependencies.
It turned out that our dependencies were already sane
(with the sole exception of a direct dependency to X-Lib
in the XV viewer widget)
The XV-Viewer widget in our GUI uses four direct calls
to the X-Lib. This was discovered by strict dependency checking,
as mandated by new Debian policy
...this will be the second preview release
Lumiera is still in pre-alpha stage, and thus there
are no proper releases, just preview snapshots
from time to time.
But we're providing Debian packages allready
- upgrade the configuration to a current version
- provide a frontpage with cross-links to other documentation
- define a set of modules; relevant classes and files can be
added to these, to create a exploration path for new readers
- fix a lot of errors in documentation comments
- use a custom configuration for the documentation pages
- tweak the navigation, the sections and further arrangements
Note: this drops some backwards compatibility. We're targeting now
roughly the range between Ubuntu-Precise (LTS) and Debian/testing,
with Debian/stable as the reference system.
The naming scheme for Boost-Libraries was adjusted with Boost-1.42
for Unix-Platforms. Now the '-mt' suffix isn't included any more, but
the libraries available through the usual packaging mechanisms can be
assumed to be thread safe.
See also http://issues.lumiera.org/ticket/759
tests used to be defined ad hoc and test definitions
are scattered confusingly over various directories.
Now built some simple rules into the buildsystem
to allow organising the tests into layers and
linking them accordingly.
Note: this switches to building shared objects
for the test classes too, which effectively speeds up
both re-building and re-running of test cases
