Closed DavePearce closed 2 days ago
@delehef Is there anything specific about the way the project is structured to note? For example, you were specifically trying to keep the static / dynamic libraries as small as possible?
Some modules are only included with the main binary, and not with the library. Its unclear if they are left out for some reason.
Because the lib only needs (needed?) what is required to expand traces, feel free to increase the public API surface.
The project does not build a normal
lib
What do you mean by a normal lib? It compiles a .so
/.dylib
for now.
I mean we have this in the Cargo.toml
file:
[lib]
crate-type = ["cdylib", "staticlib"]
I understand why you have this, but it actually has implications meaning tests in tests/
can't be compiled (which I don't fully understand yet). To resolve that issue, I can include the normal lib
crate-type like so:
[lib]
crate-type = ["lib","cdylib", "staticlib"]
Looks like there is an issue for this raised, though unclear whether its actually considered a bug or not.
Also, are both cdylib
and staticlib
needed? I'm assuming one is linked on the Go side, so the other ... is not needed?
For now, I think this is not a priority :)
Currently, the project is configured in a slightly unusual fashion which doesn't quite fit the normal project layout. In particular, this makes testing more awkward. Notes:
lib
, which means that tests in thetests/
directory cannot access it as a crate.tests/
directory (and other clients) cannot use the tool.main
binary, and not with the library. Its unclear if they are left out for some reason.These can all be changed relatively easily, though its not clear whether there was any specific reason for structuring like this.