rusty-bits
commented
2 years ago Hello HQuest, Thank you for your continued interest in my tools.
however coming from your old shell based tool, a bit sad on how limited it currently feels
I'm sorry you feel this way, one of the reasons I moved to Rust (besides using it as a means to learn Rust) was to allow an easier method to have more functionality, not less. As it stands now, the user no longer needs any local dependencies. git, curl zip etc. etc. are all part of the binary straight out of the Rust crates so nothing special needs to be done by the user.
The Configuration.pdf is parsed on the fly so any changes Acidanthera makes to the config is reflected immediately with no updates needed. Any new version of OpenCore that's released is available immediately etc.
If run from the EFI partition the EFI folder is updated on the fly with no need to copy resources over.
Any missing or extra fields in the config.plist can be added or removed automatically on the fly.
I don't really know in what way it's limited now, since features like these were not available easily before the Rust version.
It seems this tool aggregate files from Dortania
Well, not exactly, Dortania has the build repo that is tied to the auto build of the Acidanthera commits. My tool isn't doing anything with the Dortania builds other than checking if the builds repo config.plist has been updated. This was a design decision while working with the Acidanthera devs (mainly the ones that work on the Dortania builds repo) to ensure all the builds would be coming from one unified source.
The option to specify on the fly which version of OC to use is great, but not sure if allowing usage of a previous version has any implications with newer Lilu and friends
Well, it's not as if octool knows anything about specific versions, it just lets you pick from the versions available in the build repo including the daily builds as they happen. I'm not sure what that has to do with Lilu and Friends to be honest.
the ability to compile modules from their sources. Any chances of this feature to make a come back?
I'm not sure why this would be needed, as soon as any updates get committed to Acidanthera they are built by the Git Hub actions and attached to the Dortania builds repo. This usually takes around 30 minutes or so, do we really need the ability to compile locally when the user can just wait 30 minutes and is sure they are using the exact same binary as everyone else? I might be missing something, though.
Another "missing" feature is the ability to add other extension sources (such as VoodooI2C) into a list of extensions to be fetched online.
Yes, this is an issue I noticed that and changes the user makes to the other.json file, for example, will be erased when octool is run. I have added an option to have octool leave the local config files untouched as part of octool v0.4.4, but haven't pushed the update yet. As to VoodooI2C, isn't that in there already, or was that just an example of something that's outside of the Dortania builds?
On the octool update front, it seems (from a comment on another issue) your tool does not auto update, since it is a binary file. Perhaps you could add the compiled binaries into the git repository ...
Maybe, but for now I'm more concerned with how this could wipe a users config, etc. so it's not something I am contemplating at the moment even though the compiled binaries are already part of the git repo.
After a long hiatus on the OSX scene, I am back, and decided to give your rust-based tool a shot. Being able to run it purely on console is what keeps me hooked in. I'm impressed on how easy it is to do what it does, however coming from your old shell based tool, a bit sad on how limited it currently feels. It seems this tool aggregate files from Dortania, with a nice front-end to the ocvalidate tool. The option to specify on the fly which version of OC to use is great, but not sure if allowing usage of a previous version has any implications with newer Lilu and friends - should not, but again, keyword should.
One great advantage your previous shell code had was the ability to compile modules from their sources. Any chances of this feature to make a come back?
Another "missing" feature is the ability to add other extension sources (such as VoodooI2C) into a list of extensions to be fetched online. Not sure how easy (or feasible) would be to add them to the config.json manually - perhaps via a "custom.json" file added into the INPUT/ folder and read during build time to make it less prone to be overwritten during updates.
On the octool update front, it seems (from a comment on another issue) your tool does not auto update, since it is a binary file. Perhaps you could add the compiled binaries into the git repository, with their respective checksums, and add a call to fetch and process these files during a self updating routine. Makes for a more user-friendly experience.
Keep up with the great work, and thank you for the tool!