Changed the file structure

[snake-4]

• Moved source code files to a folder called src, modified the Makefile to output the object files and the executable files to a folder called build in the src folder.
• Moved cpu_features into a submodule.

Compiles fine on Ubuntu(GCC 9.3.0).
Absolutely no source files were changed, they were only moved.
Only changed files are the starch's Makefile template, starch generated Makefiles, project's Makefile, Makefile.cpufeatures, CI files and the .gitignore.

[mutability]

My main question here would be - why? What does the restructuring help us do better?

Re submodule vs inline, IIRC the main drivers for inlining a copy were

a) git submodules are a bit janky when it comes to doing clean updates - I frequently ended up with a working copy that was out of sync with the repository
b) getting CI checkouts etc right in the face of submodules gets messy

[snake-4]

Moving the source files to a separate folder results in easier navigation of the repo as it prevents other folders such as the test files or the tools from getting mixed up with the source files, also having a separate folder for the object files and the executable files result in a cleaner source folder when developing in my opinion.
Also for moving a submodule to the latest commit the command git submodule update --remote --merge with a git commit afterwards to create a commit which changes the submodule's commit hash can be used.
Right now in my PR the cpu_features is at the latest commit of it's master branch as of the time of writing, this means that every user who clones the repo or does git submodule update will get that exact version of the submodule.

[mutability]

This is, to some degree, painting the bikeshed. Do you run into build problems if the source files are not separated out?

If we're going to rearrange all the source (which has implications for downstream forks, commit history etc) then I'd rather wait until I have time to do a proper overhaul. In particular I'd like to look at CMake..

Re submodules, the issue was not "how do I update the submodule". The issue was that I'd regularly get my working copy into a state where "git pull" said that everything was up to date, but the submodule was actually at a different commit compared to the upstream repository. (Even with the config option to recurse pulls into submodules set). I didn't spend too much time diagnosing why, but that was a show-stopper - I was getting reports of build failures on an apparently up-to-date working copy that were fixed by wiping the existing working copy out entirely and re-cloning.

[snake-4]

I understand, I'll close this PR now and create a new Windows support branch without the dependency of this.

[mutability]

Thanks! While this one didn't work out at the moment, I do appreciate the effort that goes into making PRs, thanks for submitting them.