The CAPI Manifesto

Fawzi Mohamed fawzi at gmx.ch
Sat Oct 22 18:12:12 PDT 2011


On Oct 22, 2011, at 4:03 AM, Timon Gehr wrote:

> On 10/22/2011 04:33 AM, Walter Bright wrote:
>> On 10/21/2011 4:32 PM, Fawzi Mohamed wrote:
>>> 
>>> On Oct 21, 2011, at 4:20 PM, Fawzi Mohamed wrote:
>>> 
>>>> The main problem with this approach is how to support different
>>>> versions of
>>>> a library, or of OS. It quickly becomes difficult to support anything
>>>> but
>>>> the latest, or a fixed version. It works beautifully for mature libs.
>> 
>> Since github has excellent support for branches, I don't see why this is
>> a major problem.

do you have a repo per library? if yes then indeed it is feasible. I didn't think about that.

>>>> I still cannot avoid thinking that a C frontend automatically
>>>> generating D
>>>> modules with the help of recipes would be a better way. It will need
>>>> some
>>>> manual intervention for "difficult" cases, mainly giving manual
>>>> translation
>>>> of some macros, but it should be small.
>>> 
>>> … and it seems that in the time I was offline others came up with the
>>> same
>>> idea...
>> 
>> It's an old idea. The trouble is, as always, the C preprocessor. I'm
>> currently converting the openssl .h files, and they are a zoo of
>> metaprogramming using C preprocessor macros.
>> 
>> People are going to demand perfect translation if it is automatic.

that was the reason I talked about recipes that can add manual fixes where needed (for selected macros).

>> 
>> The only way to do it is to work with the preprocessed output of the .h
>> file, and just forget about the preprocessor.
> 
> Another way is to replace the preprocessor with CTFE and string mixins. I think that could be automated quite easily. (modulo the possibility of some extremely heavy abuse on the C side that could make the other parts of the translation a lot harder of course)

I think string mixings are an extremely ugly solution to this problem, and I would try to avoid that, especially if they are used to represent a function that should be inlined, and might be replaced by a normal function in a later version.




More information about the Digitalmars-d mailing list