Purpose of dggal-rust sub-directory?

[jerstlouis]

What is the purpose of this:

dggal-rust/dggal-rust/src/lib.rs

Line 1 in 420c274

pub use ecrt::*;

?

This dggal-rust sub-directory probably adds confusion to the different crates inside the workspace.
The DGGAL module already imports the necessary things from ecrt.
Is this only to use Application instead of ecrt::Application?
Given the generic nature of application, it might be desirable to explicitly write ecrt::Application::new in the one place at initialization time so that it is clearer that this initializes the eC runtime's Application abstraction.

The other relevant things from ecrt might be ecrt::Pointd and perhaps a few other things if one uses the readDGGSJSON() function which returns a very eC-native object, but it might be best to let the user explicitly import specific things form ecrt as needed, instead of automatically importing everything that ecrt defines.

[MichaelJendryke]

That was just meant to be the place for re-exports. Please take a look at this test branch that I just started https://github.com/GeoPlegma/dggal-rust/tree/unified-crate I know it goes back to one crate only, but as long as I need the four tools ear etc. this seems like the only way I see to get this to crates.io. I did a small test with cargo publish --dry-run and it seems to build and run just fine. I will keep this on a separate branch and not even merge it until I am sure the separated version does not work.

Edit: I had to re-wire a few imports in e.g. dggal.rs to make it work

[jerstlouis]

@MichaelJendryke What are the issues that come up with this main branch when trying to publish?

cargo build does work for it right (I was able to build it)

Also regarding the ecere directory in both branches, might I suggest to use upstream instead to avoid confusion with the pre-sdk-explosion ecere library (https://github.com/ecere/ecere-sdk/tree/latest/ecere).

[MichaelJendryke]

Yes, we can build it, but a whole workspace cannot be published, it needs to be published member by member, so crate by crate, and since we need the ecere/eC and ecere/dggal code in multiple places it would either have to be separated or shipped entirely for each crate. But than there is the issue with dggal, which would still need ear etc. to compile and the dggal crate would have ecere/eC and ecere/dggal. Maybe we discuss this again, what the options are.

[jerstlouis]

@MichaelJendryke Could we make dggal-sys depend on ecrt-sys in [build-dependencies], and the build.rs of dggal-sys will therefore have all the eC/ source directory available from that build dependency, but will still run make in that eC directory again making the tools available to build the native dggal-sys (even if this ends up in separate isolated directories and unfortunately results in building the eC tools twice)?

There may be related unstable features:

https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#artifact-dir

https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#build-dir