this check may look weird, but in fact a similar check in the
old version of the singleton factory helped us spot a problem
with Clang, most likely but of the compiler or runtime system
Clang doesn't allow to declare a private nested class as friend.
This is unfortunate, but likely correct to the letter of the standard.
As a workaround, now we're creating the instances within a static
function of DependencyFactory -- in the end this improves readability
A second issue fixed with this changeset is the scope of the
marker function. Clang is right, this isn't ADL, thus an inline
friend definition is simply not visible outside the class.
lib::Depend<TY> works as drop-in replacement for lib::Singleton<TY>
This changeset removes the convoluted special cases like
SingletonSub and MockInjector.
explanation: we use pthread_once to define a mutex type descriptor,
used to define some of our mutexes as recursive mutexes. Now,
pthread_once relies on a counter stored in a given location;
we used a non-exported global var for this counter.
Unfortunately this ties the mutex initialisation to the static
initialisation of the compilation unit holding this counter variable.
Theoretically it would be possible (we never observed such an incident)
that, during static initialisation, a singleton was brought up,
which requires a class-scoped lock, implemented as recursive mutex.
And it would be possible for this singleton locking to happen prior
to initialisation of the mentioned counter variable.
As a fix, I've moved the counter varialbe into a function scoped
static variable, since that is guaranteed by the C++ runtime system
to be initialised at first usage of the function, irrespective of the
initialisation order of the enclosing compilation units
clang-3.2 requires a clarification here (while previous versions
of clang and GCC automatically resolved the ambiguity by assuming
use of a nested, dependent template).
Clang is more insistent when it comes to enforcing 'protected' visibility.
Since in this case the basic design can be considered sane and optimal, the
only (and obvious) solution is to nest the PIMPL into a default base class
for implementation; this mirrors the structure of the interface.
Compilation with Clang 3.0 (which is available in Debian/stable) fails,
mostly due to some scoping and naming inconsistencies which weren't detected
by GCC. At some instances, Clang seems to have problems to figure out a
perfectly valid type definition; these can be resolved by more explicit
typing (which is preferrable anyway)
by providing a custom copy function one can adjust otherwise non-copyable
elements. This should be used cautionary because dereferencing elements may
poison the cache and thus have some considerable performance impact
(profile this)
using our util::_Fmt front-end helps to reduce the code size,
since all usages rely on a single inclusion of boost::format
including boost::format via header can cause quite some code bloat
NOTE: partial solution, still some further includes to reorganise
this draft fills in the structure how to get from an invocation
of the engine service to the starting of actual CalcStream instances.
Basically the EngineService implementation is repsonsile to
instruct the Segmentation to provide a suitable Dispatcher.
This is necessary since the implementation of the job functions
calls through the VTable of the interface JobClosure. Thus this
interface (and the VTable definition) needs to reside within
some compilation unit linked together with the basic job class.
TODO: move class Job entirely into the Backend
now builds for me on Debian-7 Wheezy 64bit
unqualified member functions in dependent base classes not found anymore.
Need to qualify either the class or the instance.
...for the very specific situation when we want
to explore an existing data structure, and the
exploration assumes value semantics.
The workaround then is to use pointers as values.
...attempt to build it based on the monadic iterator primitives.
Only problem is: need to find out relation between nodes
after the fact. In the real usage situation, this
is not a problem, since we have a state object
there, which can track the relation as it is established
basically I've changed my mind to prefer an
infinite JobPlanningSequence, which is just
evaluated partially. This removes the need to
embody the logic of planning chunk generation,
which really is a different concern.
decision: the base for any deadline calculations
is the expected real time corresponding to the grid origin.
This value is contained in the Timings record.
this clarifies the relation of TimeAnchor and Timings,
the latter act as a general spec and abstracted grid,
while the latter actually performs the conversion and
deadline checking
Rationale: this is the *support* Library.
The real "Lumiera-Library" does not exist yet.
liblumiera.so will be the *interface* every external
module / plug-in uses to get Lumiera functionality.
Especially the work on Library dependency clean-up
made outright clear, that this interface library
needs to be a separate piece of software, which is
carefully crafted, and more-or-less depends on the
whole application.
the buildsystem will now pick up and link
all test cases according to the layer, e.g.
backend tests will automatically be linked
against the backend + library solely.
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
Our libraries constitute a clear dependency hierarchy,
we do not want circular dependencies. Declaring these
dependencies while creating the shared libraries would
allow strict checking by the linker; but unfortunately
this also creates transitive depdendencies stored as
DT_NEEDED tags.
While basically this would be just fine, the resolution of $ORIGIN
on gets confused in case of transitively defined library dependencies
over multiple hops, especially in case when actually no symbol of this
transitive dependency is used. Since these newer systems set the
--as-needed switch for linking by default, these unnecessary
DT_NEEDED entries will be purged from the executable, but of course
not from the shared library causing the transitive dependencies.
As a consequence, when loading the executable, the $ORIGIN resolution
mechanism doesn't act on the dependencies recorded in the library,
causing the shared loader to abort with an "unresolved dependency"
So the resolution for these problems is not to use transitive
dependencies on libraries intended to be found via $ORIGIN
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
while refactoring, I thought it might be a good idea
only to use Query objects. But in this special case,
most often you'd just want to pass in a simple query
with a literal query string. So this convenience shortcut
indeed makes sense.
