tags:

views:

36

answers:

2

I have this C++ file (let's call it main.cpp):

#include <string>
#include "main.y.c"
void f(const std::string& s) {
  yy_switch_to_buffer(yy_scan_string(s.c_str()));
  yyparse();
}

The file depends on main.y.c, which has to be generated beforehand by means of bison util. In other words, I can't compile main.c file if I forget to run bison main.y before it. And it's perfectly OK, this is how I want it. Now I'm trying to build .d file from Makefile, using this command:

$ c++ -MM main.c > main.d
main.cpp:2:10: error: main.y.c: No such file or directory

I fail here, since main.y.c is not ready yet. I think that I should somehow quote my #include directive in the main.c file to make it invisible for c++ -MM process.

+1  A: 

You can indicate in your makefile that main.c depends on main.y.c so that it'll run the bison process before it tries to compile main.c.

As an alternative (which I think is probably not what you want to do) is that you can have your makefile pass a macro to the compiler to indicate whether or not main.y.c exists and use an #if directive to include (or not) main.y.c.

#if EXISTS_MAIN_Y_C
#include "main.y.c"
#endif
Michael Burr
Won't the macro thing hide the real problem ? If the file is not generated but needed anyway, not including it will just make the real problem less obvious.
ereOn
@ereOn: that why I said it's probably not a good solution. I probably shouldn't have added that... There are times when you might want to conditionally include a header that might or might not be on a platform. In which case you might conditionally include code that contains custom implementations of the missing platform functionality. autoconf is commonly used to set up macros that let you do this, but you're right that's not really what this user needs here.
Michael Burr
+3  A: 

This sounds like a job for a makefile. You can set the dependencies such that main.c depends on main.y.c, and main.y.c has a rule to build it from the bison code.

Mark B