Closes #29
Closes #14
Would also resolve issues such as: discussions#127
This PR includes support for the cargo 3ds new command, as well as a small refactoring of the project needed to implement the new functionality.
List of changes:
cargo 3ds new is now recognized as an official command. Once run for a new directory it will create a new custom project. The differences between cargo 3ds new and a standard cargo new for now are simple: automatically adds ctru-rs (via git repository for now) as a dependency of the project, writes a completely custom main.rs which uses the ctru::prelude to run a simple "Hello, World!" program, and adds an empty romfs folder + Cargo.toml configuration to get RomFS working more easily.
As my mention of #14 can tell, modifying the RUSTFLAGS is now not needed, and that call has been removed. This is thanks to those same changes in the linking mechanism within rustc that let us get away with link ordering problems. As such, libctru linking isn't specified twice anymore, instead it only depends on the calls within the ctru-sys build script.
Since cargo-new is the first subcommand we officially support which does not compile any code, many changes have taken place within cargo-3ds to ensure more flexibility. Now the cargo arguments are added based on the command and every subcommand can specify an "after-cargo" callback to work with external functionality (e.g. build creates the .3dsx file in its callback, as well as new does its changes there too).
I will update the ctru-rswiki shortly after this PR merges to briefly explain the new functionality.
With this PR I intend to officially release cargo-3ds via crates.io. I haven't had any issues with cargo-3ds for months now, and the support has only grown bigger. We can start publishing this tool as Rust3DS' first official crate, since its clearly the most mature.
Edit: I forgot to say why I decided not to implement cargo 3ds init as well. While it wouldn’t have been hard to implement it the same way as new, it posed immense issues in how we would got about actually modifying the context. cargo-init, the official one, takes an existing directory and adds to it all the files and config that would normally appear when running cargo-new. However, it does not modify existing files that correspond to the project files (e.g. if src/main.rs already exists, it skips over its initialisation). This means that by the end of the command, the folder will look more or less exactly as it would after running new, but in this case, we aren’t certain that the files present are brand new, and there’s no way of knowing that. Modifying the Cargo.toml or making a custom main.rs replacing the original one would be disastrous. The only way to solve such an issue would be to completely rewrite cargo-init, but that seems a bit out of scope for this tool.
Closes #29 Closes #14 Would also resolve issues such as: discussions#127
This PR includes support for the
cargo 3ds newcommand, as well as a small refactoring of the project needed to implement the new functionality.List of changes:
cargo 3ds newis now recognized as an official command. Once run for a new directory it will create a new custom project. The differences betweencargo 3ds newand a standardcargo newfor now are simple: automatically addsctru-rs(via git repository for now) as a dependency of the project, writes a completely custommain.rswhich uses thectru::preludeto run a simple "Hello, World!" program, and adds an emptyromfsfolder + Cargo.toml configuration to get RomFS working more easily.RUSTFLAGSis now not needed, and that call has been removed. This is thanks to those same changes in the linking mechanism withinrustcthat let us get away with link ordering problems. As such,libctrulinking isn't specified twice anymore, instead it only depends on the calls within thectru-sysbuild script.cargo-newis the first subcommand we officially support which does not compile any code, many changes have taken place withincargo-3dsto ensure more flexibility. Now the cargo arguments are added based on the command and every subcommand can specify an "after-cargo" callback to work with external functionality (e.g.buildcreates the.3dsxfile in its callback, as well asnewdoes its changes there too).I will update the
ctru-rswiki shortly after this PR merges to briefly explain the new functionality.With this PR I intend to officially release
cargo-3dsvia crates.io. I haven't had any issues withcargo-3dsfor months now, and the support has only grown bigger. We can start publishing this tool as Rust3DS' first official crate, since its clearly the most mature.Edit: I forgot to say why I decided not to implement
cargo 3ds initas well. While it wouldn’t have been hard to implement it the same way asnew, it posed immense issues in how we would got about actually modifying the context.cargo-init, the official one, takes an existing directory and adds to it all the files and config that would normally appear when runningcargo-new. However, it does not modify existing files that correspond to the project files (e.g. ifsrc/main.rsalready exists, it skips over its initialisation). This means that by the end of the command, the folder will look more or less exactly as it would after runningnew, but in this case, we aren’t certain that the files present are brand new, and there’s no way of knowing that. Modifying the Cargo.toml or making a custom main.rs replacing the original one would be disastrous. The only way to solve such an issue would be to completely rewritecargo-init, but that seems a bit out of scope for this tool.