The intended public for this document is Ceylan developers, i.e. working on the library itself: Ceylan users ought to refer to the Ceylan User Guide.
See the ChangeLog corresponding to this release. Besides this document, Windows users should refer as well to our guide for Windows build.
Not depending on the build platform (i.e. the platform on which the build toolchain will run), Ceylan sources for developers must be retrieved from SVN.
Never use exception specifications anymore, and try to remove the ones still existing whenever applicable, i.e. almost everywhere except from some virtual destructors, like the ones inherited from
The reason for that choice comes from the fact that C++ exception handling is an epic failure, see 1, 2 for more explanations.
Previous recommendation was to replace all the explicit specifications whenever possible with our exception specification macro
CEYLAN_EXCEPTION_SPEC, which was translated into an empty string (the macro was used so that this information would not be lost and could be reverted).
For example, a declaration like
void f() throw(MyExceptionType) would have become
void f() CEYLAN_EXCEPTION_SPEC(MyExceptionType).
For the sake of readability, we prefer now getting rid both of the
throw(XXX) specifications and of
The exceptions that can be thrown should only be documented in the function/method comments, with the
@throw clause. Note that if no
@throw clause is specified, then it means no exception at all is to be thrown.
If you are performing a native build (not cross-compiling), the Autotools should be used for all UNIX platforms. The build will be then drived by
Makefile.am files, and the ones that are generated from them (
If you are cross-compiling, then you should be on GNU/Linux and targeting the Nintendo DS (see our cross-compilation section).
In both cases (native or cross-compilation), for a clean and complete build, one should execute
trunk/src/conf/build/autogen.sh, preferably run with the
--full-test) option, as it builds and installs the library, and runs all available tests.
To request a cross-compilation targeting the Nintendo DS, the
--nds switch should be added. In this case, to run interactively (i.e. without using
autogen.sh) the build system, one could use for example:
In that case the fresh SVN sources are expected to be used with the Visual C++ 2008 Express free toolchain.
trunk/src/conf/build/autogen.sh script should be used with the
--nds switch. This will pass to configure the relevant
--host=arm-nintendo-ds specification and select the cross-compilation tools accordingly. For that the automatically downloaded
config.sub is automatically patched to recognize the DS.
A classical preprocessor template to handle the Nintendo DS case is:
svn co https://ceylan.svn.sourceforge.net/svnroot/ceylan ceylan
svn co --username MyUserName https://ceylan.svn.sourceforge.net/svnroot/ceylan ceylan
svn propset svn:ignore myFile .or
svn propset svn:ignore "*.log" logs/
svn rm https://ceylan.svn.sourceforge.net/svnroot/ceylan/branches --username=MyUserName
Read carefully first the Sourceforge dedicated documentation and the SVN one.
svn import ceylan https://ceylan.svn.sourceforge.net/svnroot/ceylan --username=MyUserNamewhere ceylan is a directory containing only one directory, Ceylan, that itself contains the branches, tags, trunk directories
Before reporting an error, please check you have upgraded following tools with their latest stable version available:
Some developing rules are to be enforced:
struct ceylan_mode_t ;
HAVE_CTIMEis to be replaced by
use /bin/ls -1 *.h) in CeylanMODULE_NAMEIncludes.h (ex: CeylanMathsIncludes.h)
'A specific message'to
<A specific message>
--classicalPlugwould use that layer for logging purpose otherwise. Use this latter classical plug to debug the log system, including the HTML aggregator. Finally, use
--HTMLPlugfor all other needs
We suppose here that we will create a release for current version and then prepare the setup for the next one.
x.y designates here the version to release, which should be the in-development version once stabilized.
trunk/src/conf/build/autogen.sh) to ensure no distributed file is badly managed (note however that, at least for the moment, this checking cannot fully succeed, because in general tests cannot be configured without
distchecktelling where the library was installed)
trunk/src/conf/build/visual-express/Ceylan-x.(y-1).sln), rename it (right-click, still in IDE) with newer version, then do the same for the library in solution (
save asthat library project to a file numbered accordingly, then save all (the full solution) and stop Visual Express, then add these two files to SVN repository and check them in. Rebuild everything and check with cygwin that the test suite runs fine
make effective-changelog-creation html-changelog, under
make -f MakeConfigure get-config-scripts, create
autogen.sh --chain-testto check everything is still working as expected: all the tests must always succeed, not depending on how many times they are run
make generate-releases, it should create the tar.bez2, tar.gz and zip archives. Build the resulting package on as many other hosts as possible, at least one time on each supported platform. For example,
scp ceylan-x.y.tar.bz2 $TOSFCF && sfcfto transfer the archive to Sourceforge's compile farm (if one day it comes back) and to log to their platform chooser
make api toSF)
File releases, add a release to the
Ceylanpackage (not the hidden
ceylanpackage), name that release
Ceylan-x.y, create it. Upload both release notes and ChangeLog from local tree (respectively from
trunk/ChangeLog). Upload archives thanks to
make upload-releases. Add the archives from the web interface (Processor:
Platform-Independent), File Type:
Source .zip). Send a notice. Check everything from a non-logged browser.
x'.y' designates the next version.
CEYLAN_RELEASE, and in
trunk/src/code/CeylanConfigForWindows.h. Create a new
trunk/src/conf/build/ceylan-x'.y'.pc.infile, possibly from the one of the previous version. Once updated if needed, register it in SVN (
svn add ... && svn ci ...)
trunk/src/doc/web/main/documentation/DocMenu.htmlso that this new version is referenced
trunk/src/doc/web/main/News.htmlwith the starting date of this new release
trunk/src/conf/generateBugReport.sh, it will generate a text file containing the report, and tell you what to do with it
make distor, preferably,
If you have information more detailed or more recent than those presented in this document, if you noticed errors, neglects or points insufficiently discussed, drop us a line!