Ticket #101 (new enhancement)

Opened 1 year ago

Last modified 1 year ago

libburn module for the D programming language

Reported by: Anders Owned by: pygi
Priority: major Milestone:
Component: libburn Version:
Keywords: Cc:

Description

I translated libburn.h (0.3.6) into D. It works, but I didn't test it extensively so bugs are expected (typos, etc).

compile: dmd program.d libburn.d -L-lburn

program.d: import libburn; void main () { do stuff }

Attachments

libburn.d.txt (11.5 kB) - added by Anders 1 year ago.

Change History

Changed 1 year ago by Anders

Changed 1 year ago by Anders

If there are any other headers you want translated, poke me on IRC (Anders, Freenode) and I'll do them... thanks

Changed 1 year ago by scdbackup

  • priority changed from trivial to major
  • type changed from bug to enhancement

I understand this header enables libburn applications written in D. That's appealing. Do you have such a D application already ?

But: To implement sustainable support for D, we would have to repeat your work after any change of the API or we would have to do all changes in parallel. That's not very appealing. It implies the risk to have inconsistencies in the libburn package.

Better would be to have an automat which converts libburn.h into libburn.d . Automat written in C or bash, so it does not widen our system requirements for libburn development.

Question is wether to put libburn.d into libburn/ or into extras/ .

Mario: do we already have a plan for our foreign language strategy ? (Who will teach extras/java that there are new API functions burn_drive_set_buffer_waiting() and burn_drive_get_best_speed() ?)

Changed 1 year ago by Anders

There are tools to convert C headers into D, but output isn't always that great. I can keep it up to date with new versions of libburn.

It should probably go into extras, seeing as it's not used by any other stuff in the libburn package :)

I did put 10 minutes to porting the libburner program, but I ran into problems (none of which were impossible to solve)... so I didn't continue. I'll probably port it later when I have some time left.

Changed 1 year ago by scdbackup

If the generation of libburn.d can be done autmatically by a tool which does not need much extra software then it might be appropriate to put it into libburn.

The extras/ department is rather for language wrappers. I understand D can use libburn's functions directly.

About a libburner in D:

I had a glimpse on D at www.digitalmars.com/d . It might be quite unappealing to D programmers to use libburn's C API directly. Although it has object oriented semantics it still is strictly procedural C and it implies the typical risks of C programming.

So possibly it is better to write some wrapper classes around libburn's API which would allow to handle the libburn objects (i.e. libburn instance, drives, media, disc images, tracks, ...) in the usual ways of D.

That wrapper would then be used by demo programs like test/libburner and test/telltoc.

Note: See TracTickets for help on using tickets.