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
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
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
- to make it similar to Cehteh's tests, moved my testcode to tests/components
- made scons build the errortest and plugin-example as well
- scons check will run the suite
please note, my implementation work is quite incomplete (warnings, app shuttdown
not yet implemented); I hadn't success running the plugintest.
