[ https://issues.apache.org/jira/browse/AVRO-1936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Thiruvalluvan M. G. updated AVRO-1936: -------------------------------------- Component/s: c++ > avrogencpp, includes should have more guards or generate more headers > --------------------------------------------------------------------- > > Key: AVRO-1936 > URL: https://issues.apache.org/jira/browse/AVRO-1936 > Project: Avro > Issue Type: Bug > Components: c++ > Affects Versions: 1.8.1 > Reporter: Alexander Moriarty > Priority: Major > > Inside of an avdl file, one can include other avdl files. But the generated > only one header file is generated and it does not include guard the > enums/structs which were defined in the other avdl files. > I have some basic records which I've defined in there own avdl files, and > include them inside of more complicated structures. > All is well, until I try to include multiple of the avro generated header > files. > Inside of your AvrogencppTests you have gotten around this by giving each > generated type there own name space. > As a test, I quickly modified the existing avrogencpp.cc to include an > optional name to CodeGen::guard. > {code:none} > std::string guard(const string& name=""); > [...] > string CodeGen::guard(const string& name) > { > string h = name.empty() ? headerFile_ : name; > makeCanonical(h, true); > return h + "_" + lexical_cast<string>(random_()) + "__H_"; > } > {code} > And then adding guards around each Enum, Record, Union, Traits, etc. > Which works well enough. However... the guards do not include the namespace > names, so this change breaks your unit tests. > As long as two higher level classes in the same namespace do not include the > same subclasses the generated header files can both be used, but if you have > a basic data type like an Point(x,y) which is used throughout the higher > level classes then they will both redefine Point(x,y) > On the Java side, everything is okay. Point(x,y) and all of the classes which > include Point are in their own files inside of a package. > Is there any common way around this problem? -- This message was sent by Atlassian JIRA (v7.6.3#76005)