[xsd-users] RE: xsd bypasses customized types

[Richard Cresswell]

Boris, that fixed the xsd tree generation, but the generated code
still does not compile.  It creates a default constructor of form:

DerivedObject::
DerivedObject ()
: ::base::BaseObject ()
{
}

Shouldn't it detect that DerivedObject is derived from the custom type
and create the correct constructors?

Applying the patch also broke tests/cxx/tree/name-clash/inheritance.
Could this be because of other missed patches?  I noticed that
name-processor.cxx had changed quite a bit between 3.2 and the patch
that you provided.  Your

cc.set ("cxx-tree-name-processor-stem-set", NameSet ());
cc.set ("cxx-tree-name-processor-member-set", NameSet ());

was still

c.context ().set ("cxx-tree-name-processor-stem-set", stem_set);
c.context ().set ("cxx-tree-name-processor-member-set", member_set);

in my code.

I am concerned that my codebase diverges too much from where you are
with 3.3, but I am reluctant to upgrade to the 3.3 beta since I will
need to patch again when you do the final release.  Do you have an ETA
for when the official 3.3 will go out?

Thanks again, I appreciate your effort and quick responses.

Richard

On Mon, Apr 19, 2010 at 3:35 PM, Boris Kolpackov
<boris at codesynthesis.com> wrote:
> Hi Richard,
>
> Richard Cresswell <rcresswell at gmail.com> writes:
>
>> Boris, I am having trouble using the patch you provided.  If I use the
>> --custom-type option for derived objects as you suggested below, xsd
>> throws a FrontendElements::Context::NoEntry exception (originating
>> from a call to FrontendElements::Context::get at
>> xsd/cxx/tree/name-processor.cxx:1018).
>
> I also discovered (and fixed) this bug while working on the from-base
> fix. Here is the patch:
>
> http://scm.codesynthesis.com/?p=xsd/xsd.git;a=commit;h=c7a135cc66ab0270cebc04664dad7baa2e4c3818
>
> For this bug you only need the changes to the name-processor.cxx.
>
> Boris
>