[Proposal] Embed Samurai ninja files runner?

[cyanidle]

I would like to propose to ignore haters in Youtube comments section and stick to ninja files.

Reasons:

1. ninja is fast
2. ninja.build is readable and great for debugging build system issues
3. It is cross-platform

But the usability of mate.h may be improved by embedding C-rewrite of ninja: samurai
into the mate.h header.

I am not sure if this is a good idea, considering the sheer size of it in terms of LOC

[cyanidle]

I could try to do a PR in my spare time for this, if you dont mind

[cyanidle]

The runner could also be bootstrapped inside build directory instead of recompilation on any mate.c change

[sten-code]

The philosophy of having the build system in C, is so that you can compile your project exclusively with a C compiler.

It's fine to have a dependency to ninja in order to mature the build system, but eventually you would want to swap it out for a custom solution.

Edit:
For the samurai proposal, I like the idea, but there are several downsides:

• Big dependency
  • Every time the build file changes, samurai would also have to be recompiled as it would be included in the header file, which will probably cause slow compile times.
• Licensing
• Embedding
  • This would be a nightmare to maintain and embed inside of a single file.

[TomasBorquez]

@sten-code makes a good point, their licensing is permissive but it starts to get messy if we have two, we could switch to theirs, keep both, make two versions, fork or look for a different solution.
The rest of the problems shouldn't be an issue, the dependency is medium sized, we'd have to see how it affects building, for now I will pass on the idea since making the ninja build files is relatively simple but in the near future we can look into it

[cyanidle]

I just think that this project should continue using ninja files (and improve at that). But embedding samurai (the whole source code as a text block, which is dumped into build directory to be compiled once on first configure) would allow to remove dependency from ninja, but keep producing ninja files

[sten-code]

Another solution could be something like this:

int main(int argc, char* argv[]) {
    StartBuild(argc, argv);
    {
       // ...
    }
    EndBuild();
}

Then when running mate you can do something like this: ./mate --ninja or ./mate -t ninja which would generate ninja build files. This would allow for multiple build systems to be used, including a self hosted solution.

[TomasBorquez]

Another solution could be something like this:

int main(int argc, char* argv[]) {
StartBuild(argc, argv);
{
// ...
}
EndBuild();
}
Then when running mate you can do something like this: ./mate --ninja or ./mate -t ninja which would generate ninja build files. This would allow for multiple build systems to be used, including a self hosted solution.

This would indeed work but I would prefer to just keep the self-hosted solution in the future anyways and I don't care about breaking backwards compatibility for now since its the early days of the project.

I slept on it and already decided I want samurai so I'll be seeing how I can integrate samurai into the project the following weeks

[sten-code]

@TomasBorquez Alright, but what do you think about the ability to take in arguments?

[TomasBorquez]

@sten-code I guess it would make static bool needRebuild() easier since we could send --rebuild as an argument or something, but even then we can do it without args, I don't mind adding them later but for now they would just be clunky

[sten-code]

I meant as general options like thread count, selecting which target to compile, etc.

[TomasBorquez]

I meant as general options like thread count, selecting which target to compile, etc.

That's what I wanted void CreateConfig(MateOptions options) for

[sten-code]

What if you want to compile a specific target?

For example in make you can compile a specific target like this: make examples