Conditional compilation controlled on type level

[KOLANICH]

Let we have a container format using a bunch of other formats. And let's assumme thet we don't need most of them.

I mean, look at pcap.ksy. It refers lots of formats relevant only in network context. If I want analyse only USB captures with my program, I don't need them all.

Let's make some definitions. We can treat a set of all the types as a DAG (directed acyclic graph): a type is a vertex, if a type refers some type there is an edge from the referer to referee. For the purposes of this issue we call B a subDAG of a DAG A if and only if B≠A ^ (V(A-B) ∩ V(B) = ∅) where V(A) gives the set of vertices of the graph A.

The idea is to provide an an additional argument to the compiler, which should refer a config file. In that file we should be able to write rules to select the types which are:

• to be included with all their subDAGs, and everything which is not explicitly included is excluded.
• to be excluded with their subDAGs
• to be included, but their subDAGs are to excluded;

Then the compiler should act according to the rules. When a type is excluded the compiler should insert a code calling the callback in that branch instead of the code parsing the type and not to generate the imports and not to compile the type and its subDAGs. The callback should be programmer-defined. The default one should be to throw an exception or finish the program if there is no exceptions.

[GreyCat]

I recall we had a proposal for an alternative approach somewhere — i.e. instead of huge lists like

type:
  switch-on: some_packet_id
  cases:
    1: some_external_type_1
    2: some_external_type_2
    3: some_external_type_3
    # ...

which also require every of these external types to be imported, instead this main file would declare some "extension point", and not list any of these files explicitly. And all these "some_external_type_*" would instead have some connection mechanism in their header, which would effectively find that "extension point" and inject their ID and type into it.

I'm not sure about the exact implementation (and I can't seem to be able to find that discussion), but I wonder if that would be slightly more straightforward than doing these include/exclude rules file?

[koczkatamas]

Maybe you were referring to this issue? #71

[GreyCat]

@koczkatamas Yeah, exactly. Your original proposal was buried under the heap of direct import-related discussion topics.

[KOLANICH]

Do you mean inclusion of the whole directory and specifying the enum values as metadata for types?

I don't see how this solves this problem, but I guess there should be a separate issue for this idea. Also I guess that scattering a single enum between multiple files opens a can of worms: we cannot just open a file and see what values are defined, we have the compiler to do that work itself. May be it's not bad if the compiler can resolve conflicts. Also in differrent formats differret subformats may have diferrent enum values. I guess an explicit mapping between enum and type is easier to observe.