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
'scons none' will not build anythinf but runs the configuration checks to
determine if the system and libraries are sane to build Lumiera, this will
be used in builddrone later.
The goal is to make the build scrips more clear
at first sight. So move the main build targets
into a separate SConscript, to make them similar
to the tests, research and tools.
The final goal of this makeover is to reduce
the main SConstruct as much as possible
a long standing error, uncovered recently due to more stringent
checks of the linker on newer platforms, not picking up direct
dependencies of an executable transitively from the linked-to
dynamic libs (which is fine).
The error was to *overwrite* the LIBS construction variable
in the definition of the executable to link, instead of just
adding our dynamic links to the sources to be linked.
Not sure if this works; problem is that the icons
generated from SVG are just dumped into the target
folder, but we miss to generate the respective
installation targets
especially this means to use the common well-known names again,
like "Program" "SharedLibrary". The customisation now happens
invisible in LumieraEnvironment.
the installed lumiera exe can even be started...
...well with a bit of cheating: you need to cd into the lib/lumiera
because the PLUGINPATH problem isn't solved yet
