-
Notifications
You must be signed in to change notification settings - Fork 1
Description
But I have a feeling that it's the best way or something very similar is the best way, so I'm not really sure what should be done about it.
The current implementation is basically "we have information about what flags will be used to compile the final cppm file, so let's just overwrite the cppm file with the content #include "${header name}" and pass that to gencppm so it can take advantage of the compilation database".
One alternative would be to parse the compile_commands.json and output a modified one that specifies the file as the header file instead. But honestly, I think the current way is good even though it's weird.
Another alternative might be to pass the name of the cppm file to gencppm, and then it would be able to get the compilation database entry for the cppm file and use those args to analyse a "fake" translation unit - an in-memory buffer which is generated by gencppm, containing the #include directive or something along those lines.
I currently prefer the second option more, because supporting the "macro constants" like #define PI 3.14 may be possible with an approach where gencppm generates other "fake" translation units and analyses them.