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.
