[Proposal] CLI arguments parsing

[cyanidle]

@sten-code @TomasBorquez About arguments. I think They should be parsed arbitrarily inside StartBuild(argc, argv) (like CMake -D ARG=xxx) and then queried by the build script

Maybe like this:

String arg = Argument("arg");

Also consider adding BuildDir, SourceDir global read-only variables, or functions to get these values. They are useful during commands formatting

This is a separate issue to continue discussion in #2

[TomasBorquez]

you think GetSourceDir() and GetBuildDir() works? and we keep the state static and local

[cyanidle]

I think it is better to add hierarchy here.

Like CMAKE_SOURCE_DIR: but Mate()->SourceDir

Signature: const MateBuiltins* Mate(void);

What do you think? Kinda verbose, but it is better than polluting global namespace (there could be a LOT of such variables in future)

[sten-code]

Another thing to consider is how to parse the arguments. We could use the getopt.h header, which is standardized in Linux, but on Windows it isn't.

This is roughly what the code would look like:

int main(int argc, char *argv[]) {
    int opt;
    char* some_input = NULL;
    bool verbose = false;
    
    struct option long_options[] = {
        { "verbose", no_argument, NULL, 'v' },
        { "input", required_argument, NULL, 'i' },
        { NULL, 0, NULL, 0 }
    };
    while ((opt = getopt_long(argc, argv, "hvi:", long_options, NULL)) != -1) {
        switch (opt) {
            case 'i': some_input = optarg; break;
            case 'v': verbose = true; break;
            case 'h':
            case '?':
            default:
                print_usage(argv[0]);
                return EXIT_FAILURE;
        }
    }

    return EXIT_SUCCESS;
}

In order to make this work on Windows we could use getopt-for-windows, which would be really easy to add now that we have amalgamation.

Another option would be cargs, which is cross-platform.

The same program would look like this:

static struct cag_option options[] = {
    {.identifier = 'v',
         .access_letters = "v",
         .access_name = "verbose",
         .value_name = NULL,
         .description = "Verbose"},

   {.identifier = 'i',
       .access_letters = NULL,
       .access_name = "input",
       .value_name = NULL,
       .description = "Some input"},

   {.identifier = 'h',
       .access_letters = "h",
       .access_name = "help",
       .description = "Shows the command help"}};

int main(int argc, char *argv[])
{
    int param_index;
    const char *some_input = NULL;
    bool verbose = true;
  
    cag_option_context context;
    cag_option_init(&context, options, CAG_ARRAY_SIZE(options), argc, argv);
    while (cag_option_fetch(&context)) {
        switch (cag_option_get_identifier(&context)) {
        case 'i':
            some_input = cag_option_get_value(&context);
            break;
        case 'v':
            verbse = true;
            break;
        case 'h':
            printf("Usage: cargsdemo [OPTION]...\n");
            cag_option_print(options, CAG_ARRAY_SIZE(options), stdout);
            return EXIT_SUCCESS;
        case '?':
            cag_option_print_error(&context, stdout);
            break;
        }
    }
  
    return EXIT_SUCCESS;
}

As a quick note, I haven't tested any of the code in here, so it might not even work. It is just an example of how the APIs look like.

Or we could just write one ourselves.

I do think it's important to consider the amount of lines these libraries would add.

• getopt-for-windows: 1467 lines
• cargs: 797 lines

[cyanidle]

@sten-code Both syntaxes are kinda insane. I think mate scripts should not have error handling. Build scripts are very fluid and flexible and using conventional getopt is too verbose. I think that CLI parser should be handrolled and populate dynamic variables or some static defined ones (like LLVM does it)

[TomasBorquez]

I think it is better to add hierarchy here.

Like CMAKE_SOURCE_DIR: but Mate()->SourceDir

Signature: const MateBuiltins* Mate(void);

What do you think? Kinda verbose, but it is better than polluting global namespace (there could be a LOT of such variables in future)

agreed, they could be inside of a "namespace" just for global vars, then would would have global/local state

[TomasBorquez]

@sten-code Both syntaxes are kinda insane. I think mate scripts should not have error handling. Build scripts are very fluid and flexible and using conventional getopt is too verbose. I think that CLI parser should be handrolled and populate dynamic variables or some static defined ones (like LLVM does it)

true, our version would be much smaller and much simpler, we can update it the more complex args get

[sten-code]

Both syntaxes are kinda insane.

They aren't insane in my opinion, I kind of like them. Though the only problem would be positional arguments.

I do agree it might be better to write a custom argument parser to allow for more flexibility.

I'm assuming we want the ability to use positional arguments for targets, like ./mate debug where debug is the positional argument.

There could also be a way to add custom arguments like this:

#define MATE_IMPLEMENTATION
#include "mate.h"

static struct Option opts[] = {
   {.identifier = 'i',
       .access_letters = NULL,
       .access_name = "input",
       .value_name = NULL,
       .description = "Some input"},
    {.identifier = 'f',
       .access_letters = "f",
       .access_name = NULL,
       .value_name = NULL,
       .description = "Some flag"},
};

int main(int argc, char *argv[]) {
    StartBuild(argc, argv, opts); // opts could be optional
    {
        String some_input = ArgumentString('i');
        bool some_flag = ArgumentBool('f');
    }
    EndBuild();
    return 0;
}

Usage would be:

./mate debug -f --input hello

[cyanidle]

@sten-code Why not just handle all passed args in generic way?

int main(int argc, char *argv[]) {
    StartBuild(argc, argv);
    {
        String some_input = ArgumentString('input');
        bool some_flag = ArgumentBool('f');
    }
    EndBuild();
    return 0;
}

[cyanidle]

And also there is a problem that ./mate stops working bc --input xxx was not passed. I think that arguments should be cached (set to some default value on first run and overriden if something actually was provided from cli)

[sten-code]

Doing it using options would allow StartBuild to parse all of the arguments, instead of having to parse it every time you call an argument function.

Most importantly, it also makes it clearer what kind of arguments you can actually pass to the executable, because all of the rules are defined in the same place. Having the rules in the global scope makes it way more readable.

You could also automatically generate a usage message when incorrect parameters or -h gets passed.

Nearly every single argument parser does it this way.

[cyanidle]

Mate scripts are scripts, just in C DSL! Not CLI programs. StartBuild() parses the command-line fully once, then just saves variables passed to cache, which can be accessed with Argument()