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.
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
...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.
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.
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)
...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
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
