liblumiera contains alot useful and reuseable code which is already in use by other projects
| State | Idea |
| Date | Fr 22 Apr 2011 10:46:50 CEST |
| Proposed by | Christian Thaeter <ct@pipapo.org> |
liblumiera contains alot useful and reuseable code which is already in use by other projects
Over the time we’ve put some efforts into the liblumiera. I’ve added some from my code which predates the lumiera project which I am using on many other projects. This now caused that I maintain this sources in different unrelated projects and have to cross merge and update stuff when I do updates and fixes somewhere. I think its time to factor the reuseable parts out into a independent library (like glib does for gtk), in fact I had this plan long ago.
Anything which is something tool alike and useful for other projects and not tied to Lumiera only. This are the algorithms/datastructures, allocators, tool macros. Additionally some of the src/common things should be moved into the library. I give some lists below.
Long time ago my plan was to name it ctlib or cehlib but meanwhile there is enough code done by others. So I’d propose a more neutral name, still lumieralib or lulib would be approbiate. The only thing we have to account for is that some parts which are too specific for Lumiera and should not be integrated into this spinoff need either to stay in a lumiera-internal lib (src/lib/) as currently or being moved to the respective subsystems using them (src/backend, src/proc, src/common, …), so the names should not clash.
For myself I need the C parts, while there is C code which interfaces to the C implementations and also a lot code which does nice C things on its own. This possibly means that we should in fact make 2 packages out of this, one C and one C library (where the C part is more than just the wrappers, but also the tools and tricks which are currently in src/lib/ and reuseable).
Despite a spin of I think we don’t want to change anything from our current practice and maintain it by the Lumiera developers. For many parts I feel responsible for it, but its really a part of the Lumiera codebase, despite independently useable.
We need to decide about build system and documentation system. As build system we may right start using scons. For documentation the situation is a but different since some of my code uses pipadoc/asciidoc and other uses doxygen.
Some of the code is currently quite specific to Lumiera while it could be made more generic. This is NOT subject of this RFC we may or may not do such a refactoring but this RFC and any work resulting from this should only restrict to simple things like necessary namespace and variable renaming and integration in the build system.
What belongs to the library
cuckoo hashing (cuckoo.c|h)
linked lists (llist.h slist.h)
cache lists (mrucache.c|h)
splay trees (psplay.c|h)
priority queues (not done yet)
error handling (error.h error.c) used by the other facilities too
clib convinience wrapers (safeclib.c|h) needs better name, maybe refactor into new facilities
locking, condition variables etc. (condition.c|h (rec)mutex.c|h, rwlock …)
Memory pools (mpool.c|h)
Temporary buffers (tmpbuf.c|h)
preprecessor tools (ppmpl.h) move common preprocessor macros here
polymorphic call helper for C (vcall.h)
except for some hardcoded references to lumiera_org and .lum plugin names this is quite generic, possibly moving this over could be postponed, but might eventually be done.
From src/common
interface.c interfacedescriptor.h interface.h interfaceproxy.cpp interfaceregistry.c interfaceregistry.h plugin.c plugin_dynlib.c plugin.h
The config system could become a candidate too if it ever gets finished and proved useful, but for the time being its better kept in Lumiera.
Too specific to Lumiera:
luid.c luid.h time.h
For most of the C++ parts I am not sure, ichthyo should decided upon these (please edit this here)
These look generic or wrap the C parts:
singleton-factory.hpp singleton.hpp singleton-policies.hpp singleton-preconfigure.hpp singleton-ref.hpp singleton-subclass.hpp sync-classlock.hpp sync.cpp sync.hpp thread-local.hpp typed-allocation-manager.hpp typed-counter.hpp util.cpp util-foreach.hpp util.hpp variant.hpp
access-casted.hpp advice advice.hpp allocation-cluster.cpp allocation-cluster.hpp bool-checkable.hpp cmdline.cpp cmdline.hpp del-stash.hpp diagnostic-context.hpp element-tracker.hpp error.hpp (currently too lumiera specific) exception.cpp (as before) factory.hpp format.hpp frameid.hpp functor-util.hpp handle.hpp hash-indexed.hpp iter-adapter.hpp iter-adapter-stl.hpp iter-source.hpp itertools.hpp iter-type-binding.hpp lifecycle.cpp lifecycleregistry.hpp lumitime-fmt.hpp lumitime.hpp multifact-arg.hpp multifact.hpp meta/* null-value.hpp observable-list.hpp opaque-holder.hpp optional-ref.hpp p.hpp query.cpp query.hpp ref-array.hpp ref-array-impl.hpp result.hpp scoped-holder.hpp scoped-holder-transfer.hpp scoped-ptrvect.hpp searchpath.cpp searchpath.hpp sub-id.hpp symbol.hpp symbol-impl.cpp visitor-dispatcher.hpp visitor.hpp visitor-policies.hpp wrapper.hpp wrapperptr.hpp appstate.cpp appstate.hpp basic-setup.cpp basic-setup.hpp DIR_INFO external guifacade.cpp instancehandle.hpp option.cpp option.hpp query subsys.cpp subsys.hpp subsystem-runner.hpp
logging.cpp nobug-init.cpp nobug-init.hpp streamtype.cpp streamtype.hpp test/* time/* time.cpp tree.hpp
decide on name, namespaces WIP
create git repository, setup boilerplace (build system, legalese) WIP
move all code over into the git repos, refactor (namespace renames) () WIP
make Lumiera use the new lib WIP
I am already reuse much of its code, making it independent makes maintaining it less burden
new packages, new dependencies for Lumiera instead batteries included
Back to Lumiera Design Process overview