[python][generator] Consider holder type

• holder was ignored up to now
• specifying base type holder type was not possible

@andreas.dedner Could you please have a look?

changed the description

There is clearly an issue with the holder parameter in the main method not being accessible. Not quite sure what happened there. An issue is that basesClasses is a tuple and the holder could be different for each of those.

I just checked existing code and the holder argument doesn't seem to be used - we set the holder through the options argument to load, e.g.,

    module = generator.load(includes+dfIncludes, [typeName,dfTypeName], moduleName,
                            ((*args,), (*dfArgs,)),
                            dynamicAttr=[True,True],
                            bufferProtocol=[False,True],
                            options=[["std::shared_ptr<DuneType>"],[]],
                            defines=defines)

So I'm wondering if we need:

1. holder argument similar to dynanmicAttr, e.g., in the above holder=[std::shared,None]
2. baseHolder as tuple

But perhaps there is a better way of doing it

added 1 commit

• f4cc731a - fixup generator

Compare with previous version

resolved all threads

added 1 commit

• 87ea453f - [python][generator] Consider holder type

Compare with previous version

added 1 commit

• 0cc55ca0 - [python][generator] Consider holder type

Compare with previous version

resolved all threads

changed milestone to %DUNE 2.8.0

I've tested everything and I'm happy for this to be merged. The only issue is that the 'downstream' tests are failing but I can't see why. Seems to be an issue with other MRs as well - is it okay to merge notwithstanding?

While I'm not in the position to decide this, this MR does not seem to cause the downstream issues so I would opt for merging.

merged

mentioned in commit bf619b87

picked the changes into the branch cherry-pick-bf619b87 with commit b2525d14

mentioned in commit b2525d14

mentioned in merge request !1012 (merged)