import .zng and merging Zngur files
#43
Conversation
|
The merge implementation looks good to me. I need to think a bit more about edge cases, but I guess raising error in case of conflict is safe at the start, and we can relax it later. About the user interface, what about having an It seems like a useful feature for organizing big zng files, and its implementation is basically equivalent to this feature. Also, in the future, it might enable a way for resolving conflicts using the root file. What do you think? |
|
Sure - I think adding |
|
Okay, that was pretty easy! I added a simple In general I'm having some issues getting good error messages for things like import and semantic conflicts because of how things are currently designed. |
That's great!
I'm happy with removing the
I guess we will need to pass spans in higher level representations as well. It would also be helpful for late stage errors that we currently don't have, like raising error about missing types. For testing those errors, we will probably need a function that creates a virtual filesystem like tests in rust-analyzer (Using array of file contents instead of comments makes things cleaner and simpler I think, but exact details don't matter). |
Yeah, I'll pull it to keep the API as simple as possible. I'm trying to figure out the semantics of |
There was a problem hiding this comment.
Making the example more relatable
To make this example a bit less contrived, you can create a couple C++ header/cpp pairs that make use of different rust entity subsets. You'd then create a corresponding .zng file for each.
foo.h
foo.cpp
foo.zng
bar.h
bar.cpp
bar.zng
main.cpp
main.zng
// main.zng
import "./one.zng";
import "./two.zng";
/* any entities `main.cpp` makes use of */
Ideally, "foo" and "bar" would be named after what functionality they each provide.
Import search path
There isn't a command-line interface to set the import search path, but I think we'll need this to avoid forcing a directory layout with multiple zng-containing dependencies. I think we should allow for multiple -I command-line options and, if there are none, default to the directory zng was invoked from. This is what protobuf does.
| To run this example: | ||
|
|
||
| ``` | ||
| make |
There was a problem hiding this comment.
I had to modify this command to make it work on my MacOS machine
| make | |
| make CXX="clang++ -std=c++11" |
| a.out: main.cpp generated.h src/generated.rs src/lib.rs ../../target/release/libexample_simple_import.a | ||
| ${CXX} -Werror main.cpp generated.cpp -g -L ../../target/release/ -l example_simple_import | ||
|
|
||
| ../../target/release/libexample_simple_import.a: FORCE | ||
| cargo build --release | ||
|
|
||
| generated.h generated.cpp ./src/generated.rs: main.zng | ||
| cd ../../zngur-cli && cargo run g ../examples/simple_import/main.zng | ||
|
|
||
| FORCE: ; |
There was a problem hiding this comment.
The .PHONY target is the proper way to force rebuilds in makefiles
| a.out: main.cpp generated.h src/generated.rs src/lib.rs ../../target/release/libexample_simple_import.a | |
| ${CXX} -Werror main.cpp generated.cpp -g -L ../../target/release/ -l example_simple_import | |
| ../../target/release/libexample_simple_import.a: FORCE | |
| cargo build --release | |
| generated.h generated.cpp ./src/generated.rs: main.zng | |
| cd ../../zngur-cli && cargo run g ../examples/simple_import/main.zng | |
| FORCE: ; | |
| .PHONY: ../../target/release/libexample_simple_import.a | |
| a.out: main.cpp generated.h src/generated.rs src/lib.rs ../../target/release/libexample_simple_import.a | |
| ${CXX} -Werror main.cpp generated.cpp -g -L ../../target/release/ -l example_simple_import | |
| ../../target/release/libexample_simple_import.a: | |
| cargo build --release | |
| generated.h generated.cpp ./src/generated.rs: main.zng | |
| cd ../../zngur-cli && cargo run g ../examples/simple_import/main.zng |
5e0f6a5 to
691edad
Compare
691edad to
e22b9b6
Compare
Adds a
gmcommand which takes arbitrarily many.zngfiles and a required--inflag which indicates where the generated files should be placed.This work should be considered a draft for architecture review by @HKalbasi - before spending more time improving error messages and thinking about semantic edge cases, I wanted to see if this passes the smell test.
See
examples/example-simple-mergedto get a sense of how it works. Entities are semantically merged at the pa 8000 rsing stage - unless entities conflict (e.g different layout specs), their fields are merged in predictable ways: usually, that means a union of things like methods, constructors, fields, etc.