[Proposal] Project Templates and Self-Initialization

[dsifriend]

Proposal

I realize the current implementation expects us to plop down mate.h into our own projects and go from there, but considering how much thought has gone into CLI Argument Parsing already, I want to get this proposal in early:

I think Mate, as an installable CLI tool, should be able to set itself up for you, optionally with a starter template for mate.c and maybe even a barebones file hierarchy. The reason I'm suggesting this is while it's super common for C programmers to just start a project and worry about adapting it for whatever build tool later, that's still a big point of friction. Vendor/IDE-specific build tools like Xcode, Visual Studio and even CLion (with CMake as its default) get around this by forcing a project structure on you from the start, which I also wouldn't like for Mate. As far as I know, only Meson offers something similar to what I have in mind, but it also forces a setup builddir step because of how it's architected.

I'm not proposing we make user's project structures overly strict to make things easier for us, but rather just offer and facilitate using some sane defaults. To that end, I suggest offering different defaults (templates) ranging from least to most opinionated, and using contextual cues to switch between either end of that spectrum for our default.

So to summarize:

• Self-Initialization using a CLI argument like mate init or mate -i.
  • Would copy mate.h from the CLI tool's install directory into the current directory/project root and run the cc mate.c -o mate && ./mate step for a user, at minimum.
• Project Setup using templates, specified with an optional argument to mate init.
  • Would copy or create the files and directories required for a project, including a mate.c adjusted for the chosen template, into the project root.

Implementation Details

In keeping with the spirit of the project so far, I think templates should be specified in C using Mate's existing systems as well. The templates on offer could look like the examples we currently have, in terms of structure: a src directory, a mate.c and maybe some specialized source files but primarily a src/main.c.

For self-initialization, the installed CLI tool could check if ./mate has already been built and in that case pass all its arguments to the local copy. Otherwise, the initial cp ... mate.h && cc mate.c -o mate step described above is performed first. If a particular template was specified, the local ./mate evaluates the project template, copying or creating the necessary files.

Basic Templates

There are three or four templates I think would be most useful to include for all users:

1. minimal: Only copies mate.h and compiles the local ./mate.
2. no-code: Like minimal, but provides a mate.c like in Example #01 but no src directory or source files.
3. basic: Creates a full copy of Example #01 in the new project root.
4. custom: Like basic but the provided mate.c includes examples of most important Mate functionality, with an explanation in accompanying comments, and most of it commented out to be roughly equivalent to the one included with basic.

Default Templates

Because I wouldn't like to alter the current workflow significantly for people who prefer to start working and then integrate Mate into their projects, I think the default template should switch from basic for when run in an empty directory (or one without non-hidden files if accounting for .git etc.) to minimal or no-code.

Other Notes

This is all assuming Mate is ever packaged and redistributed as a binary, but like I said at the start, I wanted to get this in early, at least to gauge interest in it.

[TomasBorquez]

I have nothing against this idea, in fact i like it, for this we depend on implementing #11, and as for distributing the binaries it can be a simple script and updated for each platform on each release.

but i think we should have both options, args can be the same for both cases, it's just that we are distributing the binaries if anyone wants them

[dsifriend]

Awesome! I'm willing to work on this myself, as well as the packaging for Homebrew, once #11 is settled. 👍