Split infrastructure types into zngur.h

[nickpdemarco]

Working towards #48, this PR splits zngur infrastructure types (rust::Unit, rust::Ref, rust::RefMut, and others) into a new zngur.h that is #included by generated.h.

This obviously comes with some infrastructure changes. Now, clients must be concerned with include paths - notice the changes to the example Makefiles to now add -I. to their C++ compiler invocations. We also now have a -o path/to/output/dir argument to zngur.

I think this is a reasonable milestone to get some feedback on the overall design. Please let me know what you think! If we do merge this, I think it should be a breaking change. We could make the default argument to -o be the CWD to approximate backwards compatibility, but I think that runs the risk of confusing users.

[nickpdemarco]

@HKalbasi looks like rust-lang/rust#115746 is hitting us again, that panic behavior is now in stable. How would you like me to handle this?

[HKalbasi]

Thanks for the PR! I'm generally on board with #48 and this implementation looks good for the start. Is it feasible to also keep the single file version working and make it configurable? I think the single file version is more suitable for small projects and people who want to try zngur. It also addresses the backward compatibility issue. Backward compatibility is not a dead end, but it is good to avoid breakage if possible, specially for this kind of breakage which affect every project.

@HKalbasi looks like rust-lang/rust#115746 is hitting us again, that panic behavior is now in stable. How would you like me to handle this?

Ah, that was decided to keep the thread id. But we can do the workaround proposed there (normalizing the output and removing the thread id) and keep the ability of auto-fixing the tests.

[HKalbasi]

I implemented the normalizing so CI should become green if you rebase on the main branch.

[nickpdemarco]

@HKalbasi I think it should be possible to support the old behavior, too. My preference is to have the new split mode the default. Would you object to smaller projects needing to invoke zngur generate file.zng --single-header?

[HKalbasi]

I don't have a strong opinion on the default. We can even go far and have no default, force user to provide either --h-file=some_thing.h or --h-directory=some_directory/ or some flags like that. We can optimize for the quick demonstrations by using the current single header as the default, but it may reduce the visibility of the multi header feature.

[adsnaider]

@nickpdemarco Do you mind if I try to get this over the finish line?

[nickpdemarco]

@adsnaider please do! Thank you. Happy to review any changes.

[adsnaider]

@nickpdemarco, I have a POC but it's running into some issues when it comes to namespaces because of how they are currently handled. Essentially, the zngur-parser and generator don't know where symbols would be located when generating the C++ output. Aside from that, it works on all other examples that make no use of --cpp-namespace. I think the prerequisite here is to make a breaking change to zngur to add an optional cpp_namespace directive to the zng file so that we can link the namespace to the types during parsing instead of at generation. This is also more important once we start splitting things into modules.

Alternatively, we need to disable namespaces altogether which seems bad but also it may be okay given that we already use the Rust module for namespacing

[adsnaider]

See #104 for different implementation