Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

versions vs. enums #31

Open
schveiguy opened this issue Jul 24, 2023 · 3 comments
Open

versions vs. enums #31

schveiguy opened this issue Jul 24, 2023 · 3 comments
Labels
preprocessor C macro / preprocessor related

Comments

@schveiguy
Copy link
Contributor

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.

@dkorpel dkorpel added the preprocessor C macro / preprocessor related label Jul 24, 2023
@dkorpel
Copy link
Owner

dkorpel commented Jul 24, 2023

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.

@schveiguy
Copy link
Contributor Author

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.

@dkorpel
Copy link
Owner

dkorpel commented Jul 24, 2023

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: ee21019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
preprocessor C macro / preprocessor related
Projects
None yet
Development

No branches or pull requests

2 participants