Namespace for inner classes in jextract

[Maurizio Cimadamore]

And, (as I'm recalling all the things we went through with previous 
incarnation of similar ideas) - dependencies.

you could have:

typedef struct Foo Bar;

What happens if you --sym Bar but not Foo?

Previously, we had some dependency tracking system which tried to pull 
in as many symbols as required (e.g. if you wanted function "baz" it 
will pull in all stuff required by "baz" so that the binding would be 
correct). This is theoretically possible, but adds a lot of complexity 
to how jextract works.

At the very least we would need to allow parsing the header into the 
intermediate IR, with some "dummy" nodes corresponding to the symbols 
that are not wanted - and then later on, do a pass to prune the IR so 
that any node that depends, directly or indirectly on a pruned symbol is 
removed too (and a warning printed about what's happening).

Maurizio

On 11/03/2021 13:55, Duncan Gittins wrote:
> On 11/03/2021 12:19, Maurizio Cimadamore wrote:
>>
>> On 11/03/2021 10:01, Duncan Gittins wrote:
>>> In my view all that is missing is command line options for multiple 
>>> "--sym symbol_to_keep" to a pick name to keep in the generation 
>>> process, and "--writeconfig myconfig.new" to write current run 
>>> options to file (for editing / split / re-submit) => a neat 
>>> formatted list of all params used by jextract PLUS list of all 
>>> symbols in the run. 
>>
>> This is a simple and nice idea - but it doesn't deal with your desire 
>> to give custom names to extracted symbols (which you brought up 
>> earlier).
>
> The filter improvement / --sym equivalent is a "must" because the 
> effect of not doing it is immediately noticable by a larger proportion 
> of those developers that try out jextract on Windows headers.
>
> Whereas the need for custom names of duplicate case-switched types 
> affects a small proportion of cases, so I'd rate it as "should/could" 
> (not essential in first release). There is a workaround for such rarer 
> cases by inlining the struct/layout into the application code as raw 
> foreign API calls - should the developer want to.
>
>> There's some validation to do when it comes to duplicate names - for 
>> instance, struct names can clash with typedef names, etc. which 
>> probably suggests that the syntax of the option will have to be more 
>> convoluted.
>
> Yes and no. It doesn't change the situation that is already present 
> with --filter for 2 headers that pulls out types with a clash, -sym is 
> just a finer degree of control of the in or out decision.
>
>>
>> Maurizio
>>
>>
>>
>>
>