Topics

1

General discussions / SFML Bindings creation mode for Emacs

« on: January 15, 2015, 09:47:55 pm »

Some of you will possibly remember that I was working on a Common Lisp Binding. No, I haven't given up, I just switched my focus to the Clasp compiler for Common Lisp, which allows direct integration of C++ libraries (no detour via C Bindings).
Anyway, as Clasp is still in early alpha, I don't think my bindings are of interest yet (SFML is practically the first library to run on it).

But I realized that something I created on the side may be of interest to other people who write or maintain bindings. My bindings creator mode for Emacs.
It does not automatically create the complete bindings, but it very much simplifies the process. I have two side-by-side windows and just put the cursor somewhere over a function or its comment, hit a key combination, and the binding for the function is automatically created in the file displayed in the other window. The same goes for classes, enums, etc., and includes differentiation between overloaded functions, a transposal of the documentation, etc..
Thus, the writer still has to go over every file, look at every function and think about it a little (which I think is good), but the repetitive task of copy&pasting and rewriting things is done away with.

My mode was written for the clbind syntax, but it can easily be adapted for any other bindings - all the necessary parsing is in there, so you just have to replace the clbind output with whatever format you need. It doesn't rely on any external parser, it simply uses regular expressions and relies on the strict adherence of the SFML files to the styleguide, which made my work much easier.

Anyway, here is the link:
https://github.com/HeyFlash/clasp-stuff/blob/master/cpp-to-clbind.el

And to give you an idea of what a result might look like (practically everything in there is generated:
https://github.com/HeyFlash/SFML/blob/master/src/SFML/Window/ClaspBindingWindow.cpp

2

C / CSFML Documentation vs. SFML Documentation

« on: May 10, 2014, 10:28:38 am »

Hi,
I am trying to write a Common Lisp binding. As the CSFML function definitions are very regular, I intend to automate as much as possible. I'd like to also automatically generate the documentation string, by parsing it together with the function definition.
However, I have noticed, that the CSFML documentation is very abbreviated compared to the SFML documentation. As an example, here is the sfRenderWindow_create documentation:

////////////////////////////////////////////////////////////
/// \brief Construct a new render window
///
/// \param mode     Video mode to use
/// \param title    Title of the window
/// \param style    Window style
/// \param settings Creation settings (pass NULL to use default values)
///
////////////////////////////////////////////////////////////

The documentation for the appropriate constructor in SFML is

////////////////////////////////////////////////////////////
/// \brief Construct a new window
///
/// This constructor creates the window with the size and pixel
/// depth defined in \a mode. An optional style can be passed to
/// customize the look and behaviour of the window (borders,
/// title bar, resizable, closable, ...).
///
/// The fourth parameter is an optional structure specifying
/// advanced OpenGL context settings such as antialiasing,
/// depth-buffer bits, etc. You shouldn't care about these
/// parameters for a regular usage of the graphics module.
///
/// \param mode     Video mode to use (defines the width, height and depth of the rendering area of the window)
/// \param title    Title of the window
/// \param style    Window style
/// \param settings Additional settings for the underlying OpenGL context
///
////////////////////////////////////////////////////////////
 

It is similar for other functions, often you have to consult the original documentation to fully understand the function.
I would assume that it'd be easier to just copy&paste the original documentation for the CSFML binding, instead of writing an abbreviated documentation. So is there a reason for this?