Ichthyostega
ceceaf4ece
Some recherche regarding the requirements and conditions of the GPL
made it clear that we are obliged to have at least an summary statement
of all authors and the years of their contributions embedded somewhere
in the source itself. The Git history alone is not sufficient to fulfil
this requirement, since a code base could be packaged as Tarball
and passed-on outside of any Git repository.
Thus I propose the following policy
- add yourself to the copyright header whenever you made
some ''significant'' contribution to a code file
- maintain a list of relevant authors at top-level,
indicating a time range of their contribution
- use the same information also in the debian/copyright (DEB package)
- clarify in the LICENSE that authorship can be extracted from Git
__Remark__: Anton Yakovlev made a single code contribution in 2009 (87e528bd),
which was never used anywhere and removed as part of a general clean-up in 2023.
Thus I do not list him as a code author, but he is mentioned in credits.txt
250 lines
8.5 KiB
Text
250 lines
8.5 KiB
Text
Refactor Liblumiera Out
|
|
=======================
|
|
|
|
// please don't remove the //word: comments
|
|
|
|
[options="autowidth"]
|
|
|====================================
|
|
|*State* | _Dropped_
|
|
|*Date* | _Fr 22 Apr 2011 10:46:50 CEST_
|
|
|*Proposed by* | Christian Thaeter <ct@pipapo.org>
|
|
|====================================
|
|
|
|
********************************************************************************
|
|
.Abstract
|
|
`liblumiera` contains a lot of useful and re-useable code
|
|
which is already in use by other projects
|
|
********************************************************************************
|
|
|
|
Description
|
|
-----------
|
|
//description: add a detailed description:
|
|
Over the time we've put some efforts into the 'liblumiera'. I have added
|
|
some from my code which predates the Lumiera project and which I am using
|
|
on many other projects. This means that I would have to maintain these
|
|
sources in different unrelated projects and have to cross merge and update
|
|
several copies of the same code when I do updates and fixes somewhere.
|
|
I think its time to factor the re-useable parts out into a independent
|
|
library (similar to what Glib does for GTK). In fact, I had this plan long ago.
|
|
|
|
|
|
.What parts are eligible for a standalone library
|
|
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.
|
|
|
|
.How to name it
|
|
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 appropriate. 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.
|
|
|
|
.C, C++ ...
|
|
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 reusable).
|
|
|
|
.Who maintains it
|
|
Despite of being a spin-off I think we don't want to change anything from our
|
|
current practice and maintain it by the Lumiera developers. In part I feel
|
|
responsible for it, while it is really a part of the Lumiera codebase,
|
|
despite of being independently usable.
|
|
|
|
.How to maintain it
|
|
We need to decide about build system and documentation system. As build system
|
|
we may right start using SCons. For documentation the situation is somewhat
|
|
different since some of my code uses pipadoc/asciidoc and other uses doxygen.
|
|
|
|
.What not to do
|
|
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 be restricted
|
|
to simple things like necessary namespace and variable renaming and integration
|
|
in the build system.
|
|
|
|
|
|
C Parts
|
|
~~~~~~~
|
|
|
|
Library
|
|
^^^^^^^
|
|
What belongs to the library
|
|
|
|
Containers
|
|
++++++++++
|
|
* cuckoo hashing (cuckoo.c|h)
|
|
* linked lists (llist.h)
|
|
* cache lists (mrucache.c|h)
|
|
* splay trees (psplay.c|h)
|
|
* priority queues (not done yet)
|
|
|
|
Runtime tools
|
|
+++++++++++++
|
|
* error handling (error.h error.c) used by the other facilities too
|
|
* clib convenience wrappers (safeclib.c|h) needs better name, maybe refactor
|
|
into new facilities
|
|
|
|
Multithreading
|
|
++++++++++++++
|
|
* locking, condition variables etc. (condition.c|h (rec)mutex.c|h, rwlock ...)
|
|
|
|
Memory management
|
|
+++++++++++++++++
|
|
* Memory pools (mpool.c|h)
|
|
* Temporary buffers (tmpbuf.c|h)
|
|
|
|
Metaprogramming
|
|
+++++++++++++++
|
|
* preprocessor tools (ppmpl.h) move common preprocessor macros here
|
|
* polymorphic call helper for C (vcall.h)
|
|
|
|
Interface system and module loader
|
|
++++++++++++++++++++++++++++++++++
|
|
|
|
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
|
|
proves itself useful, but for the time being it's better kept in Lumiera.
|
|
|
|
|
|
Not Library
|
|
^^^^^^^^^^^
|
|
Tied specifically to Lumiera:
|
|
-----
|
|
luid.c luid.h time.h
|
|
-----
|
|
|
|
|
|
C++ Parts
|
|
~~~~~~~~~
|
|
|
|
For most of the C++ parts I am not sure, _ichthyo_ should decide upon these
|
|
(please edit this here)
|
|
|
|
Library
|
|
^^^^^^^
|
|
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
|
|
------
|
|
|
|
Not Sure
|
|
^^^^^^^^
|
|
------
|
|
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
|
|
----
|
|
|
|
|
|
Not Library
|
|
^^^^^^^^^^^
|
|
------
|
|
logging.cpp nobug-init.cpp nobug-init.hpp streamtype.cpp streamtype.hpp test/*
|
|
time/* time.cpp tree.hpp
|
|
-----
|
|
|
|
|
|
|
|
Tasks
|
|
~~~~~
|
|
// List what needs to be done to implement this Proposal:
|
|
// * first step ([green]#✔ done#)
|
|
|
|
* decide on name, namespaces [,yellow]#WIP#
|
|
* create git repository, setup boilerplate (build system, legalise)
|
|
[,yellow]#WIP#
|
|
* move all code over into the git repos, refactor (namespace renames) ()
|
|
[,yellow]#WIP#
|
|
* make Lumiera use the new lib [,yellow]#WIP#
|
|
|
|
Discussion
|
|
~~~~~~~~~~
|
|
|
|
Pros
|
|
^^^^
|
|
// add a fact list/enumeration which make this suitable:
|
|
|
|
* I am already reuse much of its code, making it independent makes maintaining
|
|
it less burden
|
|
|
|
|
|
Cons
|
|
^^^^
|
|
// fact list of the known/considered bad implications:
|
|
|
|
* new packages, new dependencies for Lumiera instead 'batteries included'
|
|
|
|
Alternatives
|
|
^^^^^^^^^^^^
|
|
//alternatives: explain alternatives and tell why they are not viable:
|
|
Do nothing and handle fixes on a case by case base.
|
|
|
|
|
|
|
|
|
|
//Conclusion
|
|
//----------
|
|
//conclusion: When approved (this proposal becomes a Final)
|
|
// write some conclusions about its process:
|
|
|
|
|
|
|
|
|
|
Comments
|
|
--------
|
|
//comments: append below
|
|
|
|
.State -> Dropped
|
|
Ongoing development over the following years (after 2011) helped to clarify the situation
|
|
regarding the support library in Lumiera. The improved language standards, most notably C++14,
|
|
obsoleted most of the ad-hoc solutions in our library, since many aspects of system
|
|
integration are now handled by language and STL facilities in a satisfactory way.
|
|
On the other hand, by using the heightened capabilities of the language, some solution
|
|
patterns very specific to Lumiera could be established, gradually turning the support
|
|
library into some kind of an application framework.
|
|
|
|
It is quite common in the field of software development to put great hopes into code
|
|
reuse -- yet it is this very tendency towards a framework which prevents that ideal
|
|
from playing out as anticipated, in practice. What seems to work best is to look
|
|
at some well-made piece of software, understand how it works, and then to copy
|
|
and extract parts in order to transform it into _your own solution._
|
|
|
|
Ichthyostega:: '2025-09-16'
|
|
|
|
//endof_comments:
|
|
|
|
|
|
''''
|
|
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]
|