This explains a special repository setup which allows to merge changes made in C headers into the correct place in the D import files automatically. This new, merged parts still need to be translated into D code, but the automatic merge makes sure you don't miss a change in the C headers.

https://github.com/jpf91/systemd/wiki/Deimos-git-branch-structure

Comments are of course appreciated. The wiki page is also public, so feel free to correct mistakes. If possible, this should go somewhere into the official deimos project (wiki).

(Yes, I know there's a typo in the screenshots (daeamon) and the
screenshots don't match the text 100% as they were taken before the
text was written)
-- 
Johannes Pfau

Hey Johannes,

thanks for your great effort of writing a tutuorial. Later on you'll have to import the bindings this way:

import systemd.deimos.sd_daeamon;
import systemd.deimos.sd_readahead;

I rather prefer something like this:

import deimos.systemd.sd_daeamon;
import deimos.systemd.sd_readahead;
import deimos.mysql.mysql;
import deimos.cairo.pdf;
import deimos.cairo.svg;
import deimos.gtk.gtk;

- mta`chrono

It seems to me that people already use arbitrary ways of naming modules, IOW the deimos idea is becoming a mess:

module deimos.libsndfile.d.sndfile; https://github.com/dawgfoto/deimos/blob/master/libsndfile/deimos/sndfile.di

module ncurses; https://github.com/1100110/deimos-1/blob/master/ncurses/D/ncurses.d

module deimos.lzma; https://github.com/jpf91/deimos/blob/liblzma/liblzma/deimos/lzma.d

Personally I think naming modules "deimos.modulename" is a bad idea. What if you want to use two C libraries in a single app which both define a module with the same name?

import deimos.tests;  // wanted lib1.tests
import deimos.tests;  // wanted lib2.tests, woops!

If deimos was just a directory name and not included in the module name we could have this sort of directory tree:

/deimos/lbzma/file.di
/deimos/lbzma/c/file.h
/deimos/gtk/file.di
/deimos/gtk/c/file.h
/deimos/cairo/file.di
/deimos/cairo/c/file.h

The modules would be named as:
module lbzma.file;
module gtk.file;
module cairo.file;

And then the only thing you would have to do to start using any of these is add -I<path_to_deimos> to your projects, and you wouldn't have name clashes if you used more than one library.

On Fri, Nov 11, 2011 at 1:43 PM, Johannes Pfau <spam@example.com> wrote:

> This explains a special repository setup which allows to merge changes made in C headers into the correct place in the D import files automatically. This new, merged parts still need to be translated into D code, but the automatic merge makes sure you don't miss a change in the C headers.
>
> https://github.com/jpf91/systemd/wiki/Deimos-git-branch-structure
>
> Comments are of course appreciated. The wiki page is also public, so feel free to correct mistakes. If possible, this should go somewhere into the official deimos project (wiki).
>
> (Yes, I know there's a typo in the screenshots (daeamon) and the
> screenshots don't match the text 100% as they were taken before the
> text was written)
> --
> Johannes Pfau
>
>
When I first saw you making a branch for the c headers I kind of scoffed a bit thinking that you were just using a branch like a folder.  Reading on, though, I found what you are doing rather clever and a great way to maintain things.  Neat idea.

Regards
Brad Anderson

On Fri, 11 Nov 2011 21:43:18 +0100, Johannes Pfau wrote:

> This explains a special repository setup which allows to merge changes made in C headers into the correct place in the D import files automatically. This new, merged parts still need to be translated into D code, but the automatic merge makes sure you don't miss a change in the C headers.
> 
> https://github.com/jpf91/systemd/wiki/Deimos-git-branch-structure
> 
> Comments are of course appreciated. The wiki page is also public, so feel free to correct mistakes. If possible, this should go somewhere into the official deimos project (wiki).
> 
> (Yes, I know there's a typo in the screenshots (daeamon) and the
> screenshots don't match the text 100% as they were taken before the text
> was written)

Nice, I've tried to figure out how to get this behavior in the past, but hadn't succeeded.

mta`chrono wrote:
>Hey Johannes,
>
>thanks for your great effort of writing a tutuorial. Later on you'll have to import the bindings this way:
>
>import systemd.deimos.sd_daeamon;
>import systemd.deimos.sd_readahead;
>
>I rather prefer something like this:
>
>import deimos.systemd.sd_daeamon;
>import deimos.systemd.sd_readahead;
>import deimos.mysql.mysql;
>import deimos.cairo.pdf;
>import deimos.cairo.svg;
>import deimos.gtk.gtk;
>
>- mta`chrono

Hi,
the tutorial focuses on setting up branches to allow easy merging of c
changes, the directory names aren't that important.

Although I don't want to have a systemd.deimos namespace, it's meant to be deimos.sd_daemon and deimos.sd_readahead. I think adding a 'systemd' in there would make sense but Walter wanted libraries in deimos to follow the naming convention deimos.[c header name] and systemd uses two toplevel headers.

The reason for the additional systemd folder is that you don't want all repositories to be named as "deimos". However, it'd probably be good to add explicit moule names to the modules to make that clear.
-- 
Johannes Pfau

Andrej Mitrovic wrote:
>It seems to me that people already use arbitrary ways of naming modules, IOW the deimos idea is becoming a mess:
>
>module deimos.libsndfile.d.sndfile; https://github.com/dawgfoto/deimos/blob/master/libsndfile/deimos/sndfile.di
>
>module ncurses; https://github.com/1100110/deimos-1/blob/master/ncurses/D/ncurses.d
>
>module deimos.lzma; https://github.com/jpf91/deimos/blob/liblzma/liblzma/deimos/lzma.d

Well, once the first project is added to deimos, we'll have some kind of standard.

>Personally I think naming modules "deimos.modulename" is a bad idea. What if you want to use two C libraries in a single app which both define a module with the same name?

According to the deimos manifesto:
---------------------------------
Deimos is a collection of C header files to publicly available C
libraries and their translations to D. The idea is that if, in C, to
interface to a library one would write:
#include "foo.h"
then the corresponding D code would look like:
   import foo;
or:
   import deimos.foo;
---------------------------------
liblzma and systemD follow these conventions. Note that C libraries with multiple headers often have a kind of namespace system:

#include "cairo/foo.h"
#include "cairo/file.h"
--> import deimos.cairo.foo;
--> import deimos.cairo.file;

>
>import deimos.tests;  // wanted lib1.tests
>import deimos.tests;  // wanted lib2.tests, woops!
>
>If deimos was just a directory name and not included in the module name we could have this sort of directory tree:
>
>/deimos/lbzma/file.di
>/deimos/lbzma/c/file.h
>/deimos/gtk/file.di
>/deimos/gtk/c/file.h
>/deimos/cairo/file.di
>/deimos/cairo/c/file.h
>
>The modules would be named as:
>module lbzma.file;
>module gtk.file;
>module cairo.file;
>
>And then the only thing you would have to do to start using any of these is add -I<path_to_deimos> to your projects, and you wouldn't have name clashes if you used more than one library.

I think the C headers already have to be named in a way to avoid clashes, '/usr/include/tests.h' can only be provided by one library, so usually we shouldn't get conflicts in deimos.

-- 
Johannes Pfau

Johannes Pfau wrote:
>mta`chrono wrote:
>>Hey Johannes,
>>
>>thanks for your great effort of writing a tutuorial. Later on you'll have to import the bindings this way:
>>
>>import systemd.deimos.sd_daeamon;
>>import systemd.deimos.sd_readahead;
>>
>>I rather prefer something like this:
>>
>>import deimos.systemd.sd_daeamon;
>>import deimos.systemd.sd_readahead;
>>import deimos.mysql.mysql;
>>import deimos.cairo.pdf;
>>import deimos.cairo.svg;
>>import deimos.gtk.gtk;
>>
>>- mta`chrono
>
>Hi,
>the tutorial focuses on setting up branches to allow easy merging of c
>changes, the directory names aren't that important.
>
>Although I don't want to have a systemd.deimos namespace, it's meant to be deimos.sd_daemon and deimos.sd_readahead. I think adding a 'systemd' in there would make sense but Walter wanted libraries in deimos to follow the naming convention deimos.[c header name] and systemd uses two toplevel headers.

Scratch that, turns out the headers are actually in a systemd folder. Ubuntu doesn't provide a systemd package, and the directory structure is not visible in the source package. So it'll be deimos.systemd.sd_readahead ;-)

>
>The reason for the additional systemd folder is that you don't want all repositories to be named as "deimos". However, it'd probably be good to add explicit moule names to the modules to make that clear.


-- 
Johannes Pfau

On Fri, 11 Nov 2011 22:43:18 +0200, Johannes Pfau <spam@example.com> wrote:

> (Yes, I know there's a typo in the screenshots (daeamon) and the
> screenshots don't match the text 100% as they were taken before the
> text was written)

For the screenshots, you have used a 3rd-party GUI which is only available on *nix. Consider using gitk, which is included with git and runs on Windows.

-- 
Best regards,
 Vladimir                            mailto:vladimir@thecybershadow.net

> According to the deimos manifesto:
> ---------------------------------
> Deimos is a collection of C header files to publicly available C
> libraries and their translations to D. The idea is that if, in C, to
> interface to a library one would write:
> #include "foo.h"
> then the corresponding D code would look like:
>    import foo;
> or:
>    import deimos.foo;

Sorry, that I've to say that, but I think this is crap. A very different approach that we know from C, the D language offers a great feature called namespaces. In fact we're able to arrange our modules in the namespace that doesn't have necessarily to match with the corresponding filename.

There has always been the bump that some people wrote #include <mysql.h> and compiled with -I/usr/include instead of -I/usr/include/mysql.

Most of the .h files that are stored directly (without subfolders) in /usr/include are already covered by druntime.

So, why not just use __ONE__ convention for all the rest?

import deimos.library.modulename;

=== Examples: ===

private import deimos.lzma.base,
               deimos.lzma.block,
               deimos.lzma.container,
               deimos.lzma.version;

private import deimos.gtk.gtk,
               deimos.gtk.window,
               deimos.gtk.celllayout,
               deimos.gtk.assistant,
               deimos.gtk.misc;

private import deimos.x11.xlib,
               deimos.x11.xutil,
               deimos.x11.xos,
               deimox.x11.keysym,
               deimos.x11.xatom;

private import deimos.libpng.png,
               deimos.libpng.conf;

private import deimos.cairo.pdf,
               deimos.cairo.svg,
               deimos.cairo.ps;

private import deimos.mysql.global,
               deimos.mysql.embed,
               deimos.mysql.version;


Additionally we could provide some shortcuts. If you do import deimos.library; it will public import deimos.library.*;

=== Examples: ===

import deimos.lzma;
import deimos.gtk;
import deimos.x11;
import deimos.libpng;
import deimos.cairo;
import deimos.mysql;

And last but not least I prefer using https://github.com/D-Programming-Deimos instead of https://github.com/D-Programming-Language/deimos. Imagine if deimos becomes bigger and we'll have more than 100 pending pull requests across different bindings. That will all result in a big mess. So please each binding should have it's own repository.

If you're going to install all, then add d-p-l to your /etc/apt/sources.lst and enter apt-get install deimos-*. Or make use of a shell script that iterates through all repos in /usr/include/d/dmd/deimos and calls git pull.