www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - [deimos] [tutorial] [rfc] How to set up a git repository to

reply Johannes Pfau <spam example.com> writes:
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
Nov 11 2011
next sibling parent reply mta`chrono <chrono mta-international.net> writes:
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
Nov 11 2011
parent reply Johannes Pfau <spam example.com> writes:
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
Nov 12 2011
parent reply Johannes Pfau <spam example.com> writes:
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
Nov 12 2011
parent reply Dejan Lekic <dejan.lekic gmail.com> writes:
Johannes Pfau wrote:


 
 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 ;-)


You are my hero for making binding to systemd! \o/
I want to play with it on my Fedora box asap! :)
Nov 16 2011
parent reply Johannes Pfau <spam example.com> writes:
Dejan Lekic wrote:

Johannes Pfau wrote:


 
 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 ;-)


You are my hero for making binding to systemd! \o/
I want to play with it on my Fedora box asap! :)


It's ready to be used:
https://github.com/jpf91/systemd

But writing the bindings was really trivial, only ~12 functions and
~300 LOC(most of that documentation).

Note that there's no special function to log to the systemd log. You
have to log to stdout(for example using the standard stderr.writefln())
in a specific (but simple) format.

Also writing a daemon in systemd is actually a lot easier that the
traditional way (see
http://0pointer.de/public/systemd-man/daemon.html ), so have fun :-)

-- 
Johannes Pfau
Nov 16 2011
parent Dejan Lekic <dejan.lekic gmail.com> writes:
Johannes Pfau wrote:


 Also writing a daemon in systemd is actually a lot easier that the
 traditional way (see
 http://0pointer.de/public/systemd-man/daemon.html ), so have fun :-)
 


Sure it is easier, but less portable. :) Systemd is going to be very nice 
once it is widely adopted by various Linux ecosystems.
Nov 18 2011
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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.
Nov 11 2011
next sibling parent reply Johannes Pfau <spam example.com> writes:
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
Nov 12 2011
parent mta`chrono <chrono mta-international.net> writes:
 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.
Nov 12 2011
prev sibling parent Dejan Lekic <dejan.lekic gmail.com> writes:
I believe once Deimos will mature in time, especially if all authors of 
Deimos projects gather around and do some organisation...
Nov 15 2011
prev sibling next sibling parent Brad Anderson <eco gnuk.net> writes:
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
Nov 11 2011
prev sibling next sibling parent Jesse Phillips <jessekphillips+d gmail.com> writes:
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.
Nov 11 2011
prev sibling next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
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
Nov 12 2011
parent Dejan Lekic <dejan.lekic gmail.com> writes:
Vladimir Panteleev wrote:


 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.
 


I do not use Giggle and I understood all those screenshots. All git gui 
frontends are similar, and if a developer is familiar with any of them, 
understanding Giggle screenshots won't be a problem at all.
Nov 15 2011
prev sibling next sibling parent Dejan Lekic <dejan.lekic gmail.com> writes:
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)


Brilliant! Thanks for that, Johannes! :)
Nov 15 2011
prev sibling parent Dejan Lekic <dejan.lekic gmail.com> writes:
It is not uncommon that a certain project generates several libraries.
Example: ncurses (libcurses, libpanel, libforms)

I propose each library has a one-to-one correspondent D module inside the 
deimos package. All D modules that correspond to C/C++ header files with the 
same name should reside in subdirectories.

So, say we use ncurses for an example. We whould have:







/deimos/ncurses/cursesapp.d
/deimos/ncurses/curses.d
/deimos/ncurses/cursesp.d
/deimos/ncurses/cursslk.d
/deimos/ncurses/etip.d
/deimos/ncurses/menu.d
/deimos/ncurses/ncurses_dll.d
/deimos/ncurses/panel.d
/deimos/ncurses/term_entry.d
/deimos/ncurses/tic.d
/deimos/ncurses/cursesf.d
/deimos/ncurses/cursesm.d
/deimos/ncurses/cursesw.d
/deimos/ncurses/eti.d
/deimos/ncurses/form.d
/deimos/ncurses/nc_tparm.d
/deimos/ncurses/ncurses.d
/deimos/ncurses/termcap.d
/deimos/ncurses/term.d
/deimos/ncurses/unctrl.d

Another thing to consider is the fact that if I make such hierarchy in my 
project, I will have to SYMLINK ncurses directory into my deimos/ncurses 
folder, and also have to symlink all "library" D modules...

dmd.conf should contain -I$HOME/include/d/deimos by default. :)
Nov 18 2011