Ichthyostega
777b1286fd
Asciidoc (deliberately) does not provide direct layout controls;
however, since we are publishing directly from Asciidoc markup,
at times ''we do require such controls''
A recurring pain point is that sometimes additional (vertical) whitespace
is required for better structuring a body of text; in the past I used various
tricks that turned out to be not reliable... And through exprimentation I have
now worked out a ''canonical solution''
* Asciidoc provides a pre-defined page attribute `{nbsp}`
* when used in a separate Paragraph, this generates an ''empty paragraph'' as spacer
190 lines
7.1 KiB
Text
190 lines
7.1 KiB
Text
Design Process : Development Framework
|
||
======================================
|
||
|
||
[options="autowidth"]
|
||
|====================================
|
||
|*State* | _Final_
|
||
|*Date* | _2007-06-08_
|
||
|*Proposed by* | Cehteh
|
||
|====================================
|
||
|
||
|
||
|
||
|
||
Development Framework
|
||
---------------------
|
||
Here we collect how the tree/repository will be set up and which tools are
|
||
needed/required for working on lumiera.
|
||
|
||
|
||
|
||
|
||
Description
|
||
~~~~~~~~~~~
|
||
.Tools required:
|
||
* Unix like shell environment with standard tools
|
||
* we don't require a specific linux distribution
|
||
* Git 1.5.3 (not out yet, but really soon, we want submodules support)
|
||
* GNU toolchain, autoconf/automake (maybe SCons or something else?)
|
||
* Bouml (version case unresolved)
|
||
|
||
.Tools suggested:
|
||
* doxygen
|
||
|
||
|
||
|
||
|
||
Tasks
|
||
^^^^^
|
||
* _Cehteh_ will setup a initial repository
|
||
(see -> link:{rfc}/RepositorySetup.html[RfC: proposed repository structure])
|
||
* ichthyo has setup a debian-APT-depot at 'deb/ichthyostega.de' and will
|
||
add backport packages there if necessary so the debian-people can stay near
|
||
Etch/stable in the next time
|
||
* _Ichthyo_ volunteers to get the new source into a debian package structure from
|
||
start (same as the current cinelerra is)
|
||
|
||
.And for later:
|
||
* decide on a Unit Test framework
|
||
(see -> link:rfc/UnitTestsPython.html[RfC Unit-Tests])
|
||
* can we get some continuous integration running somewhere (nightly builds,
|
||
testsuite)?
|
||
* find a viable toolchain for writing more formal documentation.
|
||
ReStructured Text, Docbook etc?
|
||
|
||
|
||
|
||
|
||
Cons
|
||
^^^^
|
||
* Git submodules are just not usable yet; we need to come along with one
|
||
monolitic large project until they are available.
|
||
|
||
|
||
Alternatives
|
||
^^^^^^^^^^^^
|
||
* use visual studio and .NET [big]#😇#
|
||
|
||
|
||
|
||
|
||
Rationale
|
||
~~~~~~~~~
|
||
The project will be tied to a distributed infrastructure based on Git. With recent
|
||
Git submodules support it should be easy to let contributors only checkpout/work on
|
||
parts of the tree (plugins, documentation, i18n, ...). We want to build up a
|
||
set of maintenance scripts in an `./admin` directory.
|
||
|
||
At the moment we go for rather bleeding edge tools, because we want to stay at
|
||
a given version to avoid incompatibility problems. Later on a version switch
|
||
needs agreement/notification by all devs.
|
||
|
||
|
||
|
||
|
||
Comments
|
||
--------
|
||
|
||
I am always in favor of getting the basic project organization and all
|
||
scripting up and running very early in a project. I would like if the project
|
||
would take a rather conservative approach on the required Libs and Tools, so
|
||
that finally, when we get into a beta state, we can run/compile on the major
|
||
distros without too much pain. I wouldn't completely abandon the idea to target
|
||
*bsd and osX as well later on.
|
||
|
||
I would propose to move Doxygen to ``required''. The Idea to use SCons sounds
|
||
quite appealing to me at the moment. Besides that, I think this RfC could be
|
||
moved to ``Draft''.
|
||
|
||
Ichthyostega:: '2007-06-17T00:18:40Z'
|
||
|
||
Moved to Draft. For Developer documentation I would prefer doxygen. For user
|
||
documentation we can make a similar/same think like nicolasm did for
|
||
cinelerra2, means wiki for edits, git to maintain it, based on gnu texinfo.
|
||
Texinfo is quite limiting in its capabilities but it suffices, seeing the
|
||
current cin2 docs, i say its rather well done.
|
||
|
||
We need to factor out some of the proposals from this page to subpages (scons,
|
||
documentation, testing,...)
|
||
|
||
ct:: '2007-06-17T17:27:59Z'
|
||
|
||
It would really suck if we have to go through the experiences described in the article
|
||
https://web.archive.org/web/20060427005516/http://freshmeat.net/articles/view/889/[»Stop the autoconf insanity!«].
|
||
I have experienced parts of that
|
||
in the past. I have only some beginner experience with writing autotoolized
|
||
projects (mostly based on trial-and-error) and no experience in any other build
|
||
system (such as scons). As such, I still believe that autotools can be
|
||
manageable (for me personally) once the initial hurdle of learning is overcome.
|
||
|
||
I all for Doxygen documentation. Related to documentation are
|
||
http://splint.org/[Splint: Annotation-Assisted Lightweight Static Checking].
|
||
See also http://splint.org/manual/html/appC.html[descriptions of annotations (in comments)].
|
||
I suggest
|
||
that we consider using such a tool for QA. Like ct said, this should be
|
||
discussed in a subpage.
|
||
|
||
I agree with using currently bleeding-edge tools.
|
||
|
||
* _historic remark(Ichthyo):_ who wrote that comment? (neither me nor ct)
|
||
|
||
|
||
We have now a ``compatibility wiki'', finalized this proposal
|
||
|
||
ct:: '2008-03-26T13:43:26Z'
|
||
|
||
''''
|
||
|
||
{nbsp}
|
||
|
||
{nbsp}
|
||
|
||
{nbsp}
|
||
|
||
|
||
Assessment 2025
|
||
~~~~~~~~~~~~~~~
|
||
[underline]#In hindsight,# this RfC captures the baseline of our project setup. +
|
||
We soon settled upon the following toolchain, which is used up to today:
|
||
|
||
- One published Git repository per developer, with direct pull / merging; +
|
||
history is consolidated eventually into the
|
||
link:{rfc}/MasterRepositorySetup.html#historical_remark[»official Lumiera repository«],
|
||
which is made accessible at
|
||
https://git.lumiera.org/gitweb?p=LUMIERA;a=summary[`git://git.lumiera.org/LUMIERA`]
|
||
- We never used link:{rfc}/GitSubmoduleTransistion.html#_comments[Git submodules]...
|
||
- https://www.scons.org/[SCons] became the primary buildsystem soon,
|
||
with Autotools discontinued in 2011
|
||
- https://trac.edgewall.org/[Trac] is used as planning- and ticket system.
|
||
- API documentation is extracted with https://www.doxygen.nl/[Doxygen]
|
||
- Website and documentation pages are generated by
|
||
https://asciidoc-py.github.io/[Asciidoc], with source files for
|
||
documentation maintained
|
||
https://git.lumiera.org/gitweb?p=LUMIERA;a=blob;f=doc/index.txt;h=9bc0f11e6fb67588388e7616320b695841571278;hb=20f3252892d5b53a05ecd8aeb571122806baba17[in-tree],
|
||
published
|
||
https://git.lumiera.org/gitweb?p=website;a=blob;f=build_website.sh;h=60b90e18d5732d66566baf2c20a217212a5dcece;hb=aefc91e13a95a3c742dc8143c374ec982e0aa56b[automatically on push].
|
||
- A https://classic.tiddlywiki.com/[TiddlyWiki] is used for development notes
|
||
- for Unit-Tests, we use our own minimalist
|
||
https://git.lumiera.org/gitweb?p=LUMIERA;a=blob;f=src/lib/test/run.hpp;h=035633af9bde7a8053bcd304baffc21693dcf031;hb=20f3252892d5b53a05ecd8aeb571122806baba17[Test-runner].
|
||
and a
|
||
https://git.lumiera.org/gitweb?p=LUMIERA;a=blob;f=tests/test.sh;h=8c13810eb475bbacd97c528607e6750f47bb145e;hb=20f3252892d5b53a05ecd8aeb571122806baba17[shell script]
|
||
to support definition of test collections.
|
||
- A Debian package is maintained with
|
||
https://wiki.debian.org/PackagingWithGit[git-buildpackage] and published
|
||
in our own DEB depot generated by the
|
||
https://wiki.debian.org/DebianRepository/SetupWithReprepro[reprepro tooling].
|
||
- UML plays only a marginal role today -- yet in fact we generated our initial class
|
||
hierarchy with https://web.archive.org/web/20070625100128/http://bouml.free.fr/[Bouml],
|
||
as proposed by _Cehteh_. Sometimes, UML design sketches are made with
|
||
https://uml.sourceforge.io/[Umbrello], while schematic drawings,
|
||
Icons and graphic elements for the GUI are maintained
|
||
with https://inkscape.org/[Inkscape]
|
||
- Test-visualisation relies heavily on
|
||
https://graphviz.org/[Graphviz] and
|
||
http://www.gnuplot.info/[Gnuplot]
|
||
|
||
Ichthyostega:: '2025-09-20'
|
||
|
||
|
||
''''
|
||
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]
|