[
https://issues.apache.org/jira/browse/AVRO-1936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zoltan Ivanfi updated AVRO-1936:
--------------------------------
Summary: avrogencpp, includes should have more guards or generate more
headers (was: avrogencpp, includes should have more gaurds or generate more
headers)
> 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
> Affects Versions: 1.8.1
> Reporter: Alexander Moriarty
>
> 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
(v6.3.4#6332)