In the November developer meeting, Christian and I agreed that
it's best to remove that offending LUID specifications altogether.
Those embedded LUIDs where one of the issues blocking the transition to C++11
to make them stand out more prominently, some entity comments
where started with a line of starts. Unfortunately, doxygen
(and javadoc) only recogise comments which are started exactly
with /**
This caused quite some comments to be ignored by doxygen.
Credits to Hendrik Boom for spotting this problem!
A workaround is to end the line of stars with *//**
lib::Depend<TY> works as drop-in replacement for lib::Singleton<TY>
This changeset removes the convoluted special cases like
SingletonSub and MockInjector.
This is kind of a workaround to avoid having to maintain two variants.
Explanation: between Boost 1.42 and 1.52 there was the transition to a
reworked version of the filesystem library, itroducing some breaking changes
The new version distinguishes much clearer between the native and the
generic representation of paths -- which becomes relevant when porting
to non-POXIX operating systems.
Actually the intention was to use the generic path representation in all
configuration; currently this distinction is moot, since we're caring
only for POSIX systems.
So the workaround is to use the fsys::path::string() function, which
is available in both versions, but changed meaning to yield the native
string. Later, when able to deprecate older Boost versions, we should
switch to generic_string()
Note: an alternative solution was found by Mike Fisher in 3b39f35
using the compiletime define BOOST_FILESYSTEM_VERSION=2
See also ticket #896
now this library doesn't refer to any symbols from
Proc-Layer anymore. Resolving these problems
highlighted IMHO a serious shortcomming of our
interface system, which hinders the building
of abstractions at interface level
there is now a mechanism to allow sprcialised queries
to generate this syntactic representation only on demand
The actual concrete representation e.g. for scope queries
still remains TODO, but this won't really change
until we target the integration of a real resoloution engine
...to extract the syntetic ordering from
DefsRegistry and make that a responsibility
of the (internal) syntactic representation
of the query.
doesn't pass the compiler yet
effectively this joins the two existing lines
of "Query" classes into one systematic representation
Next step would be to move all mutation operations
over to the Query::Builder
time handling is part of the library, while this
convenience shortcut relies on the Advice system,
which resides in the application lib.
To allow this kind of symbolic acces to a grid
entity defined "elesewhere", client code needs
to be linked against liblumieracore.so
especially this allows to use the Advice system
or the query resolvers from within library facilities
to refer to other implementation level services by name
the rules-based configuration and query system
will be located within the core application,
while the concrete implementation facilities
are expected to reside within the session or
maybe also the GUI.
This is kind of a 'rochade' refactoring to resolve
circular library dependencies and confine the parts
dependant on the session and MObjects to the Proc-Layer
And while we're in the middle of chainsaw surgery,
we'll concentrate further query-based facilities
alongside the config-rules within the App core.
makes the test logs way more readable
Believe me: no one will ever notice a "TODO"
entry in the logs, when it showed up for
more than some months.
Thus I've created some new tickets, mostly
tagged as "QA" and placed the ticket number
at the corresponding locations in the source
connect config-facade with the new BasicSetup implementation
to fetch values from setup.ini, instead of the (not implemented)
Config-system. Hook this new lookup mechanism into the
plugin loader to retrieve the search path from there
- use custom builders
- clean up specification of target paths
- generated executable is fully relocatable
- read a bootstrap INI instead of compiled in searchpath
* refactor configure.ac to have distinct sections to configure each
subsystem.
* Dedicated LUMIERA_<subsys>_CFLAGS|_LIBS vars
* Fix Makefile.am's to use them, remove unnecessary dependencies
Stray dependencies to be refacored:
* tests/Makefile.am has dependencies on proc and backend
- should be moved to tests/library/Makefile.am etc anyways
* tests/lib/Makefile.am has dependency on GUI left
* src/tool/Makefile.am links GUI stuff generally, thats ok
* one threading test is broken, we don't care, merging new threadpool in
next.
this allows to put the proxy definitions alongside with the
actually implementing service, which makes much more sense
than having all in one huge interfaceproxy.cpp file
this allows the C++ version to provide automatic lifecycle management for
the play process, while both versions of the API (C and C++) impose only
one level of indirection.
I grepped out all flags which are actually defined/used in lumiera and
refactored them into one big tree here. There are some annotations and
issues which shall be finally resolved. Please check if the intended
hierarchy looks OK this way and add more flags when you think some are
missing. I chosen to make a quite verbose hierarchy, this doesnt cost much
in nobug and adds some flexibility. The Documentation at the head needs to
be reviewed. Many flags which are collected here need to be brought back
into the subsystems which use them, this is only to get a big picture for
now.
lumiera_error_set() now takes an optional extra string which can be used
to pass context relevant data along. This string gets copied into the
error state so one can easily create it by the tmpbuf_snprintf() facility.
Also a lot of places which define errors get fixed according to this.
Explanation: together with the bare SCons build system, on this branch I added
some dummy codefiles, to validate the build system is working as merged in from master
