dkorpel
versions vs. enums
In the project I'm working on (raylib), many #defines are specified in a config.h file, and many are specified by the makefile. Some way to distinguish between them would be helpful:
e.g.:
#ifdef PLATFORM_DESKTOP // specified by the makefile
#ifdef SUPPORT_IMAGE_EXPORT // specified by the config.h
I'd like some option of translation for these. Some I want to be version statements, some I want to be enums/static if:
version(PLATFORM_DESKTOP) {
static if(SUPPORT_IMAGE_EXPORT) {
I'm not sure how to envision this. Maybe a configuration file for ctod? I'm not sure if there would be a way to infer the right usage from the existing file. Especially since a lot of the config options are commented out in the config file, so ctod won't even see how they are defined.
I don't want to complicate ctod with a congifuration file, unless it brings significant benefits. In this case you might as well write a script to sed "s/version(X)/static if (X)/g" for all the X you want.
Yeah, I'm editing by hand now. But I'm coming to the realization that when the preprocessor is used in particular styles, handing the non-automated pieces becomes the really tedious parts.
Like, in stb_image, there's a lot of uses of 0 instead of NULL. This isn't anything ctod can deal with, but it's used all over the place, and I have to edit these by hand (I can't just s/0/null).
In general I wonder if a 2-stage tool might be the answer, one that is ctod and one that is a D front-end that knows the input came from ctod and just makes all the final adjustments.
Like, in stb_image, there's a lot of uses of 0 instead of NULL. This isn't anything ctod can deal with ...
I think there are many cases where ctod can deal with that. I added it for assignments in: https://github.com/dkorpel/ctod/commit/ee21019853021130bd048b2203b64d09bc0c60be
Assigning 0 to pointer parameters is harder, since the function type must be known inside the file.
In general I wonder if a 2-stage tool might be the answer, one that is ctod and one that is a D front-end that knows the input came from ctod and just makes all the final adjustments.
Perhaps dmd can be hacked to have pragma(Csemantics) to treat a .d file like an ImportC .c file regarding semantic analysis.