Feature: A unified tool for ease-of-life automation for the development and testing of XenevaOS on Linux or Linux-like environments.

[grep-name]

Summary

This feature addresses general problems faced by newcomers, like setting up the environment and figuring out how to get around the ecosystem, and it helps experienced devs by removing redundant steps that can easily be automated. This tool is not to be built from scratch (thankfully!); some of the work is already done in bringing some main functionality to the table, but there are a lot of features that would make everyone's life a lot simpler if implemented. Also, since the work already done is currently an executable script, it's a hassle to get to it to execute it. That's why we are to build a package (currently only Debian and Arch-based systems will be supported, later expanding according to needs 🙂).

Motivation

Soo, the reason this script is needed should be quite intuitive, but still, I would try to address those needs in these few points:

• Making the script into a package eliminates some of the risks of someone getting malicious code in and trying to sabotage developers devices.
• Will make development easier and faster as most things are to be automated, and they are a hassle to do every time (fr, writing same commands multiple times messes with my head 🤕).
• This will also eliminate the need to document how to get started, and newcomers can get started with development fairly simply (at least on Linux-like systems).
• There is this one reason, too: everyone who starts development on their devices can have different things, like QEMU versions and other subtle differences that can break Xeneva or mildly affect its working. It becomes very hard to pinpoint the problem if both developers are not using the exact same environment and packages with the same versions, too (sometimes they pose a problem, sometimes...).

Proposed Implementation

For this tool, the implementation is fairly simple; I will summarize it in some points:

• Conversion of the current script into a debian and arch based tool/package ( debian takes priority here).
• Implement XenevaOS fork repo cloning to the dependency script (also other necessary things like initrd2.img).
• Implement getopts; the script currently needs to follow strict positioning of the flags.
• Make the script smarter. Yes, the script is currently VERY dumb. I think we should implement a check that identifies what files are changed, and considering those, it only compiles the changes (this change may also need to slightly alter the makefiles or completely overhaul them).
• Give some memory to the tool. Yes, currently it has zero memory and doesn't know what the last commands were or what tool like gcc or llvm you are currently in. This will greatly make the script smarter.
• We might need to create a documentation for the tool ( i mean we do need to create documentation anyway 🫠).

Now comes some changes that might need further discussions but implanning to add those anyway

• Auto updates/pull: the tool can check if there is a new push to the original repo in the master branch or any other branch that you specify. This needs some efforts from developers, like code only getting into original repo branches when it's working (I mean, that should always be the case).
• Auto AI kickoff? This is simply pushing the build errors to an AI model and getting its response (I mean, you should be doing this, as it can be something very simple, but the compiler output is not that friendly... uh, I think you know what I mean, right?). I'm not sure about some things, so this might need further discussion.
• Keyboard shortcut to compile and run: this will save a LOT of time, as I'm frequently running back to the terminal and writing the same command. A keyboard shortcut for running it frequently makes it easier.
• I'm VERY, very unsure about this one, but decided to include it anyway: if there is an error and you are unable to solve it, then you can send diagnostic data directly to @manaskamal ! (This will also have a keyboard shortcut 😂). Jokes aside i think this feature should be in the script as it can allow other devs to help you faster and easier if we have all relevant information in our hand still need some further discussions.

As you should have noticed, the proposed implementation is very vague—and it's vague for the very reason that this tool is something we are building for our needs as developers, making it easier for newcomers to get into development directly instead of wasting time on environment setup errors when you should be fixing kernel err... Oops. Anyway, this script will take shape going forward, so it's not fixed what is to be included, and anything can change at any point in time.

Feel free to suggest any changes to the script at any point of time in its development.

Difficulty

if you are wondering how hard it would be i think it falls between easy and medium.