Split cli and compiler

[b1ek]

i think we should make another repo for the cli and leave this one for compiler to allow for more flexible embedding of amber in other projects

i wouldn't want to use cargo workspaces because it will wipe all git history and mix all issues, PR's, and releases in one repo

git history can be preserved when we move if we clone the repo to a new one and make a commit changing structure in each one

[DJMoffinz]

honestly blek i'm probably not too qualified to comment on this, but isnt the cli, how you interact with the compiler? if i'm interpreting that right, how and why do you separate those?

[Mte90]

@b1ek there is already a ticket to move the stdlib in a dedicated repository #330
I tried few months ago but there was a lot of discussion in the maintainers group to not doing it and I lost the interest.

I suggest to close this and keep to moving on the other one.

[b1ek]

this is not just about stdlib, but cli and compiler as well

[Mte90]

Yeah I know but we already discussed a lot on Discord just for stdlib and the others didn't agree to split the project in various repositories.

The stdlib is the simplest one to move on in a dedicated repo and I think it should be the first as in this way this repository has just Rust code.

[b1ek]

so we discuss splitting everything else here, and for stdlib in another issue.

discussions on discord are rather private and inaccessible compared to github issues. also here you can't just edit out what you said without anyone noticing, since it has a history of revisions rather than just an (edited) next to the message

[b1ek]

@DJMoffinz if compiler has its own crate, it allows for embedding it into other rust projects without the overhead and possible undefined behaviour of calling a binary

[Mte90]

discussions on discord are rather private and inaccessible compared to github issues. also here you can't just edit out what you said without anyone noticing, since it has a history of revisions rather than just an (edited) next to the message

Yeah but it was a long discussion that I suggest to you to read because I tried to convince the other maintainers to do that move but I was alone in the discussion.

[b1ek]

i dont think that discussion is relevant here. i am mainly talking here about splitting it into a different crate to allow for more flexible embedding. without it having anything to do with security or development experience

[Ph0enixKM]

This could enable developers to integrate the compiler better with their own projects. They could use ABI that we could expose. It's a nice feature but not a priority

[mks-h]

We can expose Amber as a library in the current git repository. As discussed previously, working with multiple repositories is an unnecessary pain — I'm against it.

[hdwalters]

We can expose Amber as a library in the current git repository. As discussed previously, working with multiple repositories is an unnecessary pain — I'm against it.

I agree with @mks-h. There's no need to create a new Git repository, as Rust packages can have multiple crates (any number of binary crates, and at most one library crate). See the Rust Book for more information on this.

In this case, the library crate would contain everything except main.rs (which conveniently contains all the CLI code). We can accomplish this with changes to the Cargo.toml file only.

[Ph0enixKM]

I agree with you guys @hdwalters @mks-h. There is no need to create new repositories. The library form factor can be achieved with creating a lib.rs and adding appropriate entries to Cargo.toml. But again... I don't think that this should be done asap.

[lib]
name = "amber-compiler"
path = "src/lib.rs"