Is your feature request related to a problem? Please describe. The functionality in /src/lib/terminal/prompt.rs would be better served by the dialoguer crate.

Describe the solution you'd like Use the premade solution instead.

Describe alternatives you've considered I tried rolling my own input system when I started writing Rust and it grew tangled and messy as scope expanded. I don't advise it.

Is your feature request related to a problem? Please describe. Locking down commits with /hooks/pre-commit makes version control and collaboration more difficult.

Describe the solution you'd like Use GitHub Actions and unit tests to ensure functionality instead.

Is your feature request related to a problem? Please describe.

Consider using a community standard logging facade: https://crates.io/crates/log Rather than the implementation we have src/terminal/ansi.rs

Describe the solution you'd like

• A logging solution which is accessible
  • Everything uses this and changing the log level will be helpful for any dependency troubleshooting

Describe alternatives you've considered None as of now

Additional context Add any other context or screenshots about the feature request here.

Is your feature request related to a problem? Please describe. If a user wants to install gcc on Windows, they currently have to run ccake install mingw. There are a couple problems with this. MinGW will not be necessary on linux machines, as gcc should be the native toolchain. A linux user should therefore not be expected to run ccake install mingw, but ccake install gcc instead. Ideally, both windows and linux users should have to type the same thing, which should be ccake install gcc.

Describe the solution you'd like If a Windows user types ccake install gcc, CCake should really treat the identifier gcc as mingw, but only on Windows.

Describe alternatives you've considered N/A

Additional context N/A

Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

ccake doesn't do anything by default when you call it with no args (e.g. ccake)

Describe the solution you'd like A clear and concise description of what you want to happen.

I would like some direction from the tool. Most tools will print a message saying what you did wrong or a help message.

Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.

I haven't considered any at this time. I suppose even a non-zero exit code would be helpful feedback.

Additional context Add any other context or screenshots about the feature request here.

Is your feature request related to a problem? Please describe. It's inefficient

Describe the solution you'd like Either use the macros or disable the feature flag

Description

Refactors config.rs and settings.rs with impl blocks

What

• Move some logic from build_project.rs to Config and Settings structs
• Add comments where necessary
• Add idiomatic impl blocks for the above structs with methods like new when necessary

Why

• To make it easier to use the Config and Settings structs
• To make it easier to read modules that use the above structs

• Restructures the project's commands into an intuitive design pattern.
• Migrates old "heavy-lifting" code into a lib folder from which the command exec functions can reference.

Description

resolves #4

Notes

Uses HashMap for aliases, but this could easily be converted into a toml file, etc. if the need for keeping all the aliases in a separate place arises.

resolves #13

Description

• Adds "commands" section to ccake.toml
• Adds "run" command to clap
• Adds run_command to lib for basic running of ccake.toml commands

Is your feature request related to a problem? Please describe. CCake's existing function set is sound enough to be able to build a simple C/C++ project, but when it comes to more complex projects that may have more needs, CCake's existing set of commands is not sufficient to complete complex tasks.

Describe the solution you'd like To allow for more complex projects, CCake can greatly benefit from custom commands that can be executed through a new command, such that the cli input looks like the following: ccake run <custom-command-name>.

These custom commands would be defined in the ccake.toml file like so:

[commands]
clean-build = "ccake build --clean"
install-build = "ccake install && ccake build"
# python and shell scripts should also be valid, not just ccake commands :)

Describe alternatives you've considered N/A.

Additional context N/A.

Is your feature request related to a problem? Please describe. Currently, install scripts will run with no problem, even if the installed tool/library is already present. This ideally shouldn't happen.

Describe the solution you'd like Within the ccake install command logic, verify that the target tool/lib is already present on the system before attempting to download. If the user really wants to redownload the package, they should be allowed to with a --force/-f flag (Ex. ccake install mingw --force or ccake install mingw -f).

Describe alternatives you've considered N/A

Additional context N/A

Is your feature request related to a problem? Please describe. Currently, ccake install will pull a download script and attempt to install the target tool/lib without any questions. The problem with this is that when used for toolchains, the toolchain may already be located on the user's system somewhere. If the versions of the ccake install target and the native toolchain match up, then the native toolchain should be preferred instead of needlessly redownloading it to .ccake/cache.

Describe the solution you'd like Search the user's system for the native toolchain and use that toolchain instead of redownloading it. If a user is trying to use gcc for example, but gcc is already present, the native gcc should be preferred only if its versioning is greater or equal to the current install target.

Describe alternatives you've considered N/A

Additional context N/A

Is your feature request related to a problem? Please describe. Currently, CCake supports installing a single toolchain such as MinGW in a global scope (within a .ccake file in the user's home dir). While this is convenient, it will become a hassle if some project A needs version X of the same toolchain that also happens to be used in another project B as version Y.

Describe the solution you'd like To avoid duplicate dependencies across multiple projects, packages should still be maintained globally, but different versions should be maintained under the same tool/lib name. Projects should contain a dependencies section where dependency identifiers (keys) along with their versions (values) can be specified. Ultimately in the CLI this would look like ccake install mingw@version where version is some version identifier specific to the tool or library. On the file system, mingw would be a folder within the .ccake/cache folder which contains folder names matching the version (Ex. .ccake/cache/mingw/x.y.z).

Describe alternatives you've considered N/A.

Additional context The prescribed design is similar to Gradle. However, this design can lead to bit rot, where unused dependencies in the global scope are no longer used, but still sit on the file system taking up unnecessary space. To help prevent this, CCake could potentially keep track of where dependencies are used in what projects. If a dependency no longer has references to any projects on the file system, it could be safely cleaned up with a ccake clean command.