Why does Foo.h need to be the "first" include for Foo.cpp?

I have a parser generator’s output that I’m embedding into my project. I get errors telling me that Parser.h must be the “first” include in Parser.cpp. This seems to be something caused by something in unreal.

I see the unholy magic that requires you to include the subclass stuff as the “last” include when you’re generating an Unreal subclass. That hasn’t bit me — and it only seems to be true for Unreal sub-classes.

But this new error is cropping up compiling code that does not include any Unreal code (and will not) … which is the parser and scanner (lexer) code.

But the output of the generator creates Parser.h and Parser.cpp along with Scanner.h and Scanner.cpp. Is it possible to turn off the requirement that Parser.cpp include Parser.h as it’s first include? It seems like a sed script in the build is my other option.

It is something enforced by the Unreal Header or Build Tool, but only because it’s a generally good practice when writing C++.

One of the features of a header is that you should be able to include it anywhere else that needs to know about that functionality/features. If that header doesn’t properly include the headers it needs (or forward declarations) then it’s possible that including it somewhere else will result in it generating compile errors because the client didn’t also include some other header they didn’t know (and probably shouldn’t know) they needed to include.

So, generally, the best way to prevent that from becoming a problem is guaranteeing that there is at least one place in the project where a header is being included without any other headers coming before it. Since a header usually has a cpp file that directly corresponds to it’s implementation that’s usually the best place to make sure that happens. And it prevents certain types of “this compiles elsewhere” sorts of compilation issues. It’s not unusual to have a cpp file that includes the header even when there may not be any code that is necessary to be put there.

OK. I get all that. Thanks for the lesson, but I still want the answer. I’m even onboard with your thesis, but I still want the answer.

How do I turn it off? In my case the parser generator is generating the parser — so I’d vastly prefer not needing to figure out where I need to change that. In addition, the parser only touches the unreal build at one well-defined point — so I can manage any include file crazy.

How do I turn it off?

I don’t know that you can turn it off. It might be possible, but frankly it’s probably not a good idea. At best you could probably turn it off for the entire solution and not just for a single file. Which, again, is probably not a good idea.

I don’t know how you’re “embedding” the output in your generator. You could just fixup that output so that the includes are the proper order, but I understand that could be onerous if your regenerating that file a lot.

If you can’t fix the generator to produce code that is compliant with that Unreal build requirement maybe it’s easier to side-step it. I believe that it relies on filename matching for that particular warning so if you were to rename the files when you add them to Unreal to Parser.h and Parser_Impl.cpp (or something like that) you wouldn’t get the error.

If I were in your shoes modifying the generator would be my first choice because, Unreal project or not, it’s current output is (IMHO) badly written C++ regardless of whether or not there’s something to enforce it like UBT.

You can’t turn this off in the default tools. The Unreal Header Tool defines a bunch of macros that the Unreal build system may require to build correctly – if there’s a chance you’re including some other header first, then that could cause hard-to-debug failures of various kinds.

If you think you understand how all of the internal details work, and you have convinced yourself that this is OK in your particular case, then you can build the engine from source, an fork the Unreal header tool to remove this check, and use that in your build. This is the benefit of having source available – you can break whatever rules you want in your own fork!

It sounds to me like your code needs to be built as an external library, then you can use that from within the Unreal code. You shouldn’t have this code in your Unreal tree.