Hello, following the instruction from https://blogs.remobjects.com/2020/06/18/importing-go-projects I tried to import the Go grpc library with EBuild version 10.0.0.2545. First I cloned the library’s files with
EBuild --mode:Island --import-go-project https://github.com/grpc/grpc-go
and then I started the build process with
EBuild github.com.grpc.grpc-go.elements --submode:Windows --debug
However building the library failed with EBuild complaining about missing sub project references. See the attached file for the debug output.
grpcb.zip (2.7 KB)
It’s still importing, but one problem I see is that you dint specify a sub-mode for the import, but then you specify a submode (which won’t work) when building…
Additionally, you’ll want to build the .sln, not the .elements project, because there are lot of secondary dependencies that got imported, and the .sln has them all, but when you build just the one project, it won;'t be able to find the other projects it depends on.
That said, after successful import and building the .sln, I do get several errors; it seems something is missing that didn’t et imported ok. I’ll need to log this for the team to have a look at next week — my apologies for not having a quick solution for you.
Thanks, logged as bugs://84914
Thank you, Marc.
Once minor bugs like this one are fixed, using Go code from other languages will be a powerful feature of Elements.
Agreed, yeah! the main difficulty is that the data for the imports can at times me, lets say, not very precise. We do have to make a lot of guesses in places. I’ll be trying to have a look at some of the failures, later today, to see what we might be missing to pull in, and why.
Found the first problem; the first dependency, github.com.antlr.antlr4, fails to compile with some missing identifiers., which seems odd, but the reason is as follows:
those missing types are fine din files named such as
atn_simulator.go. Now, Go is weird, in that it doesnt treat filenames as opaque. certain suffixes with underscore are treated as “ifdef”, for exam please a file called foo_arm64.go would only be built for arm64.
_simulator is treated the same (but maybe shouldn’t, or not always), so these files get excluded, (since we’re not building for simulator) and thus the project fails :(.
Thnk we just need to remove “simulator” form that list; I’ll do that (won’t make it into today’s build), and then see how far we get next. But this first project compiles clean if I rename all _simulator files so they don’t get skipped anymore, so that should be a good fix.
Thank you for looking into this.
Handling Go files seems to be quite complicated compared to Pascal units.
By miles, yes
Any time! I fixed a couple issues on Friday (not in the new build) that improved general behavior of the import; right now with your project i’m stuck on some missing APIs in the base go libraries Reflection class that I’ll have one of my colleagues have a look at, tomorrow.,
Big improvements/fixes made to GBL today’ I’m awaiting a new build (sadly, those take literally ~5h to run) to retest the import; I;m sure we’re not there het, but progress.
Also logged two compiler bugs (one a suspicious hint that could indicate actual bed codegen) discovered on the imported projected, so far.
84921: Go: “variable expected”
84915: Go: bogus “assgned but never read” warnings
Speaking of bugs: please see the attached project (Island, Windows). It seems as if the compiler doesn’t like local variables declared in a var block if the project references the Go runtime.
TestGoVarBlock.zip (1.9 KB)