Re: [C2hs] Looking for a new maintainer

Hi Benedikt, Thanks for the response. And I think the response times for language-c issues have been completely fine. I have no complaints there at all! It's interesting what you say about the other C parsing libraries. It sounds as though I'd got the wrong impression of them. Perhaps we would be better off trying to persuade any new C2HS maintainer to join in on the maintenance of language-c as well. That would definitely involve a smaller workload than switching C2HS over to a different parsing library. There are a few other reverse dependencies of language-c as well as C2HS ( http://packdeps.haskellers.com/reverse/language-c), but only about half a dozen of those seem to be active, so coordinating changes to language-c for C2HS that wouldn't break the other dependencies might not be so hard. I have some "tentative" interest from someone in taking over C2HS maintenance, but they're wary of being the only maintainer, so I'm trying to persuade someone else as well. If they do agree, then maybe we could get them set up with write access to language-c as well. Cheers, Ian. On 3 March 2016 at 17:13, Benedikt Huber wrote:

Hi Ian, I do appreciate your maintainance of c2hs in the past, and also do understand that response times concerning language-c extensions are not exactly short (much better now that I received an email concerning the problem, though).

However, I strongly disagree that lacking support for new C features (C11 is really not the point, because all issues so far were vendor-specific extensions) will be less of a problem if you switch to one of the other libraries you mentioned. These libraries might be the far better match for c2hs, I do not know, but you shouldn't create the illusion that they support a larger subset of C11 + gcc extensions. According to their pages, Language.C.Quote support C99 (and several interesting extensions concerning CUDA), but as far as I can see not the int128 type, for example. language-c-inline uses language-c-quote. If you could leverage clang that would be another story, but not an easy task either...

Anyways, if someone wants write access to language-c or is seriously interested in improving and maintaining it, please go ahead! Maybe it would help to move development to github - there is already a mirror anyway ( https://github.com/visq/language-c).

Best, Benedikt

Ian Ross schrieb am Do., 3. März 2016 um 12:40 Uhr:

...

Dear all,

I've been maintaining C2HS since July 2013, and I'd now like to spend my "Haskell time" on something else. That means that I'm looking for someone to take over C2HS maintenance.

The project is mature, the code is pretty clean (especially where I've not touched it!) and has relatively infrequent issues arising, but there is one *big* job that needs to be done to make C2HS viable in the long term, and anyone who takes over maintenance needs to know about this.

Bug reports for C2HS mostly fall into three categories: feature requests, "real" bugs in the logic of C2HS (fixing these varies in difficulty a lot), and finally problems caused by the C compilers and associated header files moving ahead of the language-c library that C2HS uses for parsing C headers. This third class of issues is the problem. We have been making piecemeal fixes to language-c to deal with some of these issues, but language-c was only ever intended as a parser for C99 (plus some GNU extensions), so it's falling over more and more often on C11 features that are cropping up. It's also not actively maintained, although the maintainer (Benedikt Huber) is happy to accept patches.

The solution to this problem is to move C2HS over to using one of the other C parsing libraries that are actively maintained and that support more recent C dialects -- language-c-quote or language-c-inline, for example. This is the "big job": all the AST types are different between the different parsing libraries, and language-c contains some syntactic and type analysis features used by C2HS that would need to be ported to whatever new parsing library was used. We have some ideas how to do this in a minimally painful way, but it's still going to be a bit of a slog.

On the positive side, although it's a big job, C2HS has reasonable test infrastructure in place to help -- there's a pretty extensive test suite, and a VM-based regression suite that does test builds of a number of packages that use C2HS (some of these run on Travis too).

If you're interested in taking over maintenance of C2HS, feel free to drop me a line with any questions.

Cheers,

Ian.

-- Ian Ross Tel: +43(0)6804451378 ian@skybluetrades.net www.skybluetrades.net PGP Key: 0x04490CC0/F4D6 027F 2661 745C 83A5 297D FCCC 0AE6 0449 0CC0

_______________________________________________ C2hs mailing list C2hs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/c2hs

-- Ian Ross Tel: +43(0)6804451378 ian@skybluetrades.net www.skybluetrades.net PGP Key: 0x04490CC0/F4D6 027F 2661 745C 83A5 297D FCCC 0AE6 0449 0CC0