Djinni flattens generated output

[thisismyworkgithub]

The current behaviour of Djinni flattens the generated output, regardless of the directory structure of the input *.djinni files.

Example

File Structure

Foo.djinni
bar/
|- Bar.djinni

Foo.djinni

@import "bar/Bar.djinni"
Foo = interface +c
{
    doSomething( b : Bar );
}

Bar.djinni

Bar = interface +c{}

Command

./run --idl Foo.djinni --cpp-out cpp --yaml-out yaml

Expected

cpp/
 |- Foo.hpp
 |- bar/
     |- Bar.hpp
yaml/
 |- Foo.yaml
 |- bar/
    |- Bar.yaml

Actual

cpp/
 |- Foo.hpp
 |- Bar.hpp
yaml/
 |- Foo.yaml
 |- Bar.yaml

---

Are there any plans to support preserving the same directory structure as the input djinni files? Currently this can be simulated by hackish solutions using the --*-include-prefix options -- but this requires running djinni on each file in a subdirectory independently, rather than using a single djinni file that @imports all files for an easy generation.

Using the --*-include-prefix options can also be quite fragile if a file from one subdirectory depends on a file from another subdirectory, since the @import would flatten the generated file into the new directory, leading to a duplicate file.

Could this perhaps be implemented through a flag, such as --idl-preserve-directories <true/false>?

[artwyman]

More structure in the generated output would certainly be a good enhancement, though I'm not sure that presuming a 1:1 mapping from the layout of the .djinni files and the layout of the output is necessarily what all people want either. It make more sense to group output differently, or to flatten it. I think an ideal solution would rely on a higher-level notion of grouping of Djinni types.

I think you can accomplish this today using external type support, by generating separate groups in separate Djinni runs (as you mention), and generating yaml files for consumption in later runs. We've been playing around with a Djinni package system internally at Dropbox which maps to our internal repo's module system, and automates some of the work of allowing each package to import other packages without re-generating. It's not general enough to be worth open-sourcing yet, but it also relies on running Djinni once per module.