some scripting to help creating a clean build environment for testing and bugfixes
* build_lumiera-build-dependencies.sh
All necessary steps to prepare a pristine Debian/Ubuntu/xx distro
for building Lumiera from source.
+ install the GPG pub key to trust
+ install a Lumiera DEP Repository to get the sources from
+ install build-essential
+ prepare, build and install NoBug
+ prepare, build and install libGDLmm
+ install the Lumiera build-dependencies from the DEB package
At that point, you should be able to start the build just with `scons`
* docker_open-lumiera-buildenv.sh
Additional bash magic to launch a docker container and inject the
build_lumiera-build-dependencies.sh script into an interactive shell
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
* rfcs are now all stored in the rfc folder (formerly hold the final rfcs)
* a new rfc_final folder is created
* the state folders (rfc_final|pending|parked|dropped) now contain
symlinks back to the rfc pool
the icon rendering script from Joel had a function
to invoke Inkscape; it seems this was a leftover
from earlier attempts to render the icons.
Now, we seem to rely on lib Cairor solely
