Generated include guards are insufficient

[ichernev]

Currently idlc puts an include guard like DDSC_BASENAME_H (similar for C++). However if you have 2 files with the same basename (in a different folder, for example) it will clash and you won't be able to include both :)

RTI solves this by appending a "random" number to the guard, not sure what it is, but it should be trivial to build md5/sha sum of the input IDL file and stick it in the guard. md5 is already a dependency from what I can tell (used in idl_hashid).

[eboasson]

Seems like a reasonable enough suggestion. Unless I am mistaken, MD5'ing the input will only require some minor changes to the file handling. Since macro-expansion happens before include directive processing (that is, one can a macro to specify the file to include), one probably should also take any included files into account, not just the top-level one.

Anyone looking forward to implement this? 😁

[ichernev]

md5-ying the whole IDL makes sense, it has the includes in it, so any change will produce a different hash (which is good).

We might share some code once it's done internally, but it wouldn't be me ;-)

[zijian-teng]

Is "non-standard" the only reason that we're not using #pragma once in spite of all the advantages and the fact that it is supported by ALL poplular compliers?