Mirror of the Rel4tion website/wiki source, view at <http://rel4tion.org>
Clone
HTTPS:
git clone https://vervis.peers.community/repos/yEzqv
SSH:
git clone USERNAME@vervis.peers.community:yEzqv
Branches
Tags
features.mdwn
This is a list of things the skeletons should support. Some of them are more important and will be dealt with first, and later the nice-to-have features will be added.
Status marking conventions:
- (….) - Nothing done yet
- (s…) - Just __s__tarted
- (-p..) - In __p__rogress
- (–r.) - Needs final __r__eview
- (—c) - __C__omplete
The features:
- (….) GNU standards
- (….) GNOME conventions
- (-p..) C++
- (-p..) [[Doxygen, Devhelp|api-reference]], Yelp
- (-p..) Auto-generated [[ChangeLog]] from git-log
- (….) Marking symbol visibility for shared objects
- (….) C++ header-only libraries
- (….) [[gettext|i18n]]
- (–r.) [[gitignore]]
- (….) Writing documentation
- (s…) Recursive make VS single make
- (s…) pkg-config
- (….) DocBook, Mallard
- (….) man-pages, info pages
- (….) scripts
- (….) data: images, diagrams, audio, etc.
- (….) [[Packaging]], maintenance, distribution, DEB, RPM
- (….) git
- (….) working with people: merge requests, dividing the work
- (….) git hosting, gitorious
- (….) general workflow
- (-p..) [[translation workflow|translation-workflow]]
- (….) command-line programs and program options
- (….) GUI apps
- (….) Storing user data in files
- (….) D-Bus
- (….) plug-ins
- (-p..) [[version numbers|version-numbers]]
- (….) how to add foo.in files to be process with variable (macro) replacement
- (….) [[static code analysis|static-code-analysis]] with cppcheck
- (….) [[unit testing|unit-testing]]
- (….) [[code metrics|code-metrics]] with cccc
- (….) [[valgrind]]
- (s…) [[folders]]
- (s…) [[translator list script|translator-list-script]]
- (….) [binary compatibility checker|binary-compatibility-checker]
In addition, the skeleton will contain the following files:
- (–r.) [[configure.ac|configure-ac]]
- (–r.) [[Makefile.am|makefile-am]]
- (–r.) [[AUTHORS]]
- (–r.) [[COPYING]] or COPYING.LESSER or COPYING.LIB
- (—c) [[INSTALL]]
- (–r.) [[NEWS]] (maybe can be generated from bugzilla reports and/or git commits)
- (-p..) [[README]]
And possibly the following optional files:
- (….) BUGS
- (….) HACKING
- (….) MAINTAINERS
- (….) THANKS
- (–r.) [[autogen.sh|autogen-sh]]
- (s…) [[script|copyright-notice-script]] to add copyright notice to all source files
- (–r.) [[foo.doap|doap]]
- (s…) git.mk
- (….) .gitattributes
Project Basics - This section needs to be organized and moved somewhere else
Here I’m going to track the progress of the project basics learning and skeleton implementation.
I decided to make things compile. Instead of just writing more and more code, I’d like to have some kind of compilable version which passes the tests, builds, installs and produces a distribution tarball. But I won’t use libKort directly for this, because it’s very incomplete and has only templates, so it’s too early to make it build anything, even documentation.
Instead, I’ll create a dummy project and work on it. Here are the required steps:
- Create a compilable C library
- write a simple library, a single h/c file pair is enough
- add doxygen documentation
- add some translatable strings
- make the library use autotools
- make the library use libtool and a versioning scheme
- make the library build doxygen docs
- make the library build devhelp support files
- study usage of “extern C++” in C code
- Do the same for a C++ library
- Make the C++ library have a C interface included
I’m opening a new project for this, actually 3 projects. But I’ll start with just the first one, ‘libSkeleton’. However, I want to start working with it “remote” git repositories, i.e. my gitolite server, so before I do work I want to read the Pro Git book and write some notes about git configuration and common daily processes.
Another important thing is mirrors: I want my code to be mirrored somewhere else for backup. Gitorious is a problem because it requires my server to communicate via regular direct IP, however it is probably quite reliable. An anonymous option is the I2P git hosting.
Tasks:
- Check if I2P git hosting is fine with mirroring
- Read about making gitolite (or git in general) send something to a mirror (via post-update hook), maybe a git mirroring tutorial exists on the web already
- Read Pro Git, and experiment on the testing repo (keep it under my git folder, as Partager/testing). This is my workflow: Bare repos in gitolite, and “local” working trees under Projects. Actually it may be a good idea to move the git repos folder to its own main folder, not be under Projects anymore, but it’s something I need to think about because these repos are projects after all
- Create a libSkeleton C library as described above, reusing what I’ve done for libKort but making it work for C, not C++, and adding back the gettext support I removed (check out Sylva, IIRC it had the /po folder and all required files)
- make libSkeleton a gitolite repo and apply the git practices I’ve learnt
- read about libtool usage and libraries, and write rules about version increments, etc.
- read about doxygen things and make the library export doxygen docs
- make it support devhelp
- make it have an Info manual
- make it have a manpage (e.g. nano and emacs have both man and info pages, and they aren’t identical at all)
- proceed to libSkeleton++ and then to the C interface integration…
Diary
07/09/2013
Done making a list of resources: Manuals and tutorials. Now I need to start reading the actual documents and create examples according to the guidelines they provide.
Done with initial configure.ac and Makefile.am, now need to add the other files. Then maybe check how Makefile variables are used with source files whose classes are templates, since these don’t need to be compiled but must be installed in /usr/include (This applies of course to libraries, not programs, but I do need to check whether I need to mention them in foo_sources or somewhere else or not at all).