Project files: config.toml

ReCTx will generate several files and directories on project creation. Currently, it will generate a src directory storing a main.rct, and a REAADME.md. Currently the project's generated by ReCTx have no form of configuration (customisation)...

The config.toml

As you can probably guess, the config.toml file aims to store configuration settings, project information, etc... The config file will be generated by rectx new along with the other generated files and directories. The ReCT programmer can then modify the config file which will be read by rectx during building and running do customise how they want rectx to perform certain tasks.

An example of how the config file could look:

[project]
# For storing project information
name = "example-project"
version = "0.1.0"
authors = ["user"]
remote = "github.com/user/example-project"

[profile.build]
# For storing build information (for rectx build)
compiler = "rgoc"
compiler.flags = ["-xx", "-O2"]
output.name = "program"
output.dir = "target/"
source.dir = "src/"
source.main = "main.rct"

[profile.run]
# For storing run information (for rectx run)
compiler = "rctc"
compiler.flags = ["--example-flag"]
output.name = "program"
output.dir = "target/"
source.dir = "src/"
source.main = "main.rct"

Benefits of a config.toml file

This would allow for a lot of customisation on how ReCT programmers would like their programs to compile/run. This also keeps everything in one place and could be committed to repositories allowing for easy compilation by collaborators (instead of having to explain how to compile, people will be able to just do rectx build!).

A config file also has wide-scale expand-ability! It would be very easy to add a new benchmark profile or custom profiles with something like rectx run custom-profile-name (this of course being a completely custom way for the user build/run their programs). Not to mention the example provided above is only an example of what could be possible, more fields and options could definitely be added.

New help menu

Current help menu is a bit tacky, I think it would be better if the help menu looked closer to rgoc's help menu. An example (NOT FINAL) is shown below.

---------------------
ReCTx Project Manager
--------Help---------
Usage: rectx <command>
Commands:
    help    | Shows this help message
    new     | Creates a new project
    build   | Builds the current project
    run     | Runs the current project

For more information check the GitHub page: <link>
Or join the Discord: <link>

Sub-menus

Every command should have a help menu as well, for example rectx help run or rectx help new which says more information about the command.

Colours

Use the colored cargo package to add colour to the help menu.

Generating directories

Directory generation is usually handled by the manager module. In this case, a target/ directory should be generated with the executable of the correct name inside. Each compilation profile, currently only run and build, should generate their own directory target/run/ and target/build/ respectfully. This will involve modifying manager::generate_project_executable().

In addition to the target/ directory a deps/ (for storing dependencies or files that are needed at runtime) should be generated during project creation (i.e. rectx new project-name). Any files inside the deps/ directory should be copied into the target/build//target/run/.

Milestone reference (#1)

This is the last feature needed for the v1.0.0 milestone to be complete and is referenced on the v1.0.0 section as "Add target/" and "Add /deps".

Tasks

• [x] Generate deps/ during manager::generate_project_directory()
• [x] Generate target/ during manager::generate_project_executable()
  • [x] Generate target/
  • [x] Generate correct compilation profile directory
  • [x] Compile program into target/{run/build}
• [x] Copy dependencies from deps/ into target/{run/build}

Dear Remy.

I can see that you only have support with UNIX-like systems. One good idea is to use cross-platform support from the start. I have seen lines of codes such as:

https://github.com/hrszpuk/rectx/blob/master/src/manager.rs#L82-L84

that won't work in a Windows Operating System (Since they use the Inteligent\Path\main.rct). One option is to use the rust's built-in function std::path::join function.

here are some examples: https://stackoverflow.com/questions/67816016/how-to-get-path-join-in-rust

Have a good day 👍🏽

Issue

Each build profile should have their own target folder as each build profile can have different settings. Furthermore, the application being build may require files/folders at runtime, these can be moved from /deps (default) to the build profile target directory so the application has direct access to them when it is being ran.

Solution

The implementation currently is not very flexible, although this should change when the compilation profile code is refactored in the near future. Below is a list of the features implemented.

1. build/run can be built into /target/{build|run} (default)
2. Dependencies in /deps (default) are copied into /target/{build|run}

Notes about the implementation

Currently the entire /deps folder is copied. This should be changed to only copy files/folders inside the /deps.

Current error handling problem

Current error handling has been minimal as the project is in early development. Right now, errors are just printed to the user which isn't very user friendly as many of these messages are hard to read, or aren't understandable to people know aren't knowledgeable on Rust.

Solution

To make errors better, the CLI should support a function that can send errors to the user, then each module can report errors through the CLI. Error handling should match on different error to detect what type of errors have occurred and relay why to the user. Error messages should convey the actual error at hand (PermissionError, FileNotFound, etc) and then suggest a reason why (assumptions can be made for this).

Error tags

I suggest three error tags: ERROR, ISSUE, ABORT. Each of these has varying serverity: ISSUE; for small issues that the program should be able to recover from, ERROR; when something does not go right and may or may not be recoverable, ABORT; when an issue isn't recoverable and the program is going to exit.

Example:

[ISSUE] A FileNotFoundError occurred in the Config module, maybe a "config.toml" does not exist?

Improvements to the help menu (master <- develop)

List of improvements made

• [x] Style of help menu more resembles rgoc
• [x] Help menu now has command examples
• [x] Help menu now has links to GitHub page, and Discord server
• [x] Help menu now has colours
• [x] Each command has it's own detailed help menu
  • [x] Accessible through rectx help <command>
  • [x] Detailed description of what the command does
  • [x] Example of the command's usage

Issues

• #21
• #1

Improvements made

Issues with the original help menu

The original help menu (the help menu that is currently used in the master branch as of the time of this commit) is rather ugly and does not help the user understand what each command does.

Original help menu for reference:

ReCTx :: Help Menu

Usage: rectx <command> [options]

Commands:
  help          -> shows this menu
  new [name]    -> creates a new project
  run           -> runs the current project
  build         -> builds the current project

For more information visit the GitHub page: https://github.com/hrszpuk/rectx

The brief description given for each command is very basic, in fact, you gather about has much information from the command name itself as the description give you (e.g. "run" obviously runs the project code). Furthermore, the information is not coloured whatsoever which can make it head to read, and hard to pick out important information.

In the original help menu, only one command has a more detail explanation...

Original help menu for the new command:

ReCTx :: Help Menu :: "new"

Usage: rectx new project-name

This command will create a new ReCT project with the name provided.
The project will contain: /src/main.rs, README.md, and config.toml!

For more information visit the GitHub page: https://github.com/hrszpuk/rectx

The information is still brief and does not highlight the important information. The information in this help menu is also outdated. Other commands such as 'build' and 'run' do not have their own help menu which, despite not the commands name being self-explanatory, leaves more specific information about the commands (such as configuration with config.toml) unknown to the user.

The new help menu

The new help menu aims to use colours to highlight more important information, and provide a way for users to see more information about a command.

The help command (rectx help) can now accept a <command> argument for the command the user wishes to understand more. Examples: rectx help new rectx help build rectx help run

v1.0.0 complete (master <- develop)

This pull completes the features of v1.0.0 described in #1.

Issues

• #7
• #6
• #5
• #4

Pull Requests

• #16
• #15
• #17
• #18

Issue

The original issue was outlined by Mauro in #14. To put it simply, many of the paths used in the code were for Unix platforms only (using / between items in the path).

Solution

Instead of using format! to create paths with /, I've used std::path::Path. This should relieve any cross-platform issues related to paths. In some instances where std::path::Path was not viable, I have used std::env::const::OS and format! to create the correct path.

Moved where these properties are stored based on the fact I think it makes more sense for them to be overall for the project rather than based on build/run profiles.

Issue

rectx run will try to run an executable generated by the compiler. However, if the compiler is rctc it will not generate an executable but instead generate a .dll which has to be ran with a separate command dotnet file.dll (reference).

Solution

Detect which compiler is being used and use the correct command to run the executable. This should be a simple fix in manager::generate_project_executable.

ReCTx's own config file?!

I would like ReCTx to remember some information about the user, the projects the user is developing, as well as information that may be useful to store. In order to do this, rectx will have to have it's own config file to manage. This will probably done within a new module called internal as I would like to keep user config logic separate from rectx config logic.

Where to store?

On Linux/FreeBSD/, the ReCTx config file will be stored in~/.config/rectx/rectx.toml. On Windows, it will be stored in %appdata%/rectx/rectx.toml. And on MacOS, it will be stored in ~/Library/Preferences/rectx/rectx.toml.

What to store?

• User's name
• A list of rectx projects
• Which compilers are installed

Enhancements

1. rectx new "name" should detect which compiler is installed (if any) and then generate a config file with the correct compiler set as default. This should save time for the user as they won't have to edit the config file, it should just work out of the box. If both compilers are installed, default to "rgoc", and if no compiler is installed, tell the user how to install them.
2. Instead of rectx new "name", the new command will be rectx new after which the user is asked questions for information such as project name, author name, project type, etc..

Specifics

For number 2, most information should be gathered within the cli module which then passes the information to the manager module later. This keeps everything organized (i.e. input/output is handled by cli).

Roadmap

I'd like to have a plan for how I'm going to approach different features I think ReCTx is going to have. Each set of features has a version milestone.

Version & features

v1.0.0

• [x] Custom CLI error reporting
  • [x] Check errors and report to user the issue instead of just printing the rust error message
  • [x] Add ISSUE and ABORT CLI tags (v3.0.0 features early)
• [x] Config file
  • [x] Project information (author, version, binary/library, etc)
  • [x] Building information (compiler, directory, flags, etc)
  • [x] Profiles (release, debug, benchmark, etc)
• [x] #8
• [x] #14

v2.0.0

• [ ] Automatically select different compilers when creating a new project
  • [ ] Check whether rgoc or rctc is installed and chooses between them
  • [ ] Ask user for config value like author, project name, project type, versioning, etc
• [ ] Initialise Git repository
• [ ] Added .gitignore
• [ ] Ask user for what LICENSE they would like
• [ ] Fancy CLI changes
  • [x] Add colour to output
  • [x] Special tags for Info, Process, Issue, Abort, etc
  • [ ] Progress bars 😎

v3.0.0

• [ ] Project templates
  • [ ] Customise directories
  • [ ] Customise build profiles
  • [ ] New projects can be built with the template
• [ ] Support for ReCT C libraries
  • [ ] Custom project template
  • [ ] Build profiles for C
  • [ ] Building libraries for ReCT
  • [ ] Packaging libraries for RPS

v4.0.0

• [ ] Check if packages used in ReCT files are locally installed