If this sounds like something you might be interested in I could spend a little time getting it going again.
ALL directions are valid directions! Take your LAMP scripts, for example... they're more like a story to you when you read the story and you, personally, know how to get from chapter to chapter with the least amount of effort. Someone else comes in and reads your story and they could be entirely lost. I was able to read your scripts rather easily, and if memory serves, even commended you on your note-taking and thoroughness even when you struggled with MariaDB. Yes, everything that CAN be offered is welcome! Very few things could be considered valueless here... if a build-note-file contained more of a wish list than anything but still had CC flags or a website that contained a GZ file whereas their GIT site had only a master download with no heads or tails to version management... even the URL could save HOURS of wasted work!
The hardest part is the "vision"
BTW: The build information for some base packages are in the tool chain notes, as they get built very early in the toolchain process and/or are parts of the initrd.
I'm guessing your "vision" is what I noted above to AndyJ... one person being able to "see" another person's thoughts, in writing... or be able to "read" another's chicken-scratch to make heads or tails out of it. However, I'm game! I can't afford to bring the crew in and pay their salary based on this particular vision... but down the road may be a different story!
@Everyone: There's no WRONG anything here! Currently, there's no "standard" to go by, so there's no templates to follow (yet!) but that's ~ PHASE 4 when we reach out even to some of the application
authors and see if they're willing to chip in... you know, when they're testing out a new Beta or putting up a new release... they had to compile it themselves! "Get your notes together and make 'em available!" (or better yet, grab a template and fill it in!) Even if they build on Debian, or Red Hat, or even Slack... every piece of information offered could be one less step for us to figure out on our own... and SO much less wasted PERSON time and PROCESSOR time. At the end of the day, when this project is complete, technically it could easily be retrofitted for just about any 'nix out there.
@Paul_123: The toolchain notes are a little scattered as to the WHY portion of a few things (and missing links or /src content for the last half) but I'm guessing there's a reason for the specific order of things. The links I can probably find most of via extension.tcz.info files. Manually... all by myself... at three in the morning... instead of sleeping... (LOL!)
When you see the proposed "templates" you'll see why "all under one roof" really matters. We want to be able to do everything necessary from the command line; from downloading the source "tarball" to stripping and packaging the finished product. ZERO third party content... no dependencies at all which are not required from the extension source. (ie: No Perl unless Perl is needed to create the extension itself. No PHP... not even Bash... I'm trying to put this project together using nothing more than the Common Core.) "...but I created my build using Bash!?" That's rarely ever a problem; converting Bash to (A)sh isn't all that big of a deal; I'm just trying to keep everything do-able via Busybox/Core supported functionality.
What you
could help with in the months to come, IF you don't mind - especially with TOOLCHAIN, is to create a list of dependencies (
DEP: kernel headers or
DEP: glibc-x.xx one DEP per line would be
ideal but if it's easier to copy/paste 20 into a single line... I'll take it!) at each of your
cd extension[/i] lines as the upcoming templates have two dependency lists, one for compilation, the second for runtime, so if
extension-1.23.tar.xz needs
ncurses(-dev) to compile, this is very helpful information to have up front.
YOU know why libstdc is that far down the list because you've already compiled it and found two or three things it needed before it was able to compile... but "vision" isn't seeing it yet
(How many times have you compiled something just to have to rebuild numerous times as library-xyz is a prerequisite... then app-abc turns out to be needed after that one (ESPECIALLY on apps like MariaDB where on a 2x40 CPU server can still take forever to compile just to get to 97% and hey! Another dependency!!!)
DEP: above can cut so much of that hunting out of the equation. Especially when a good number of authors don't list their dependencies, co-deps, etc. on their websites, gits, and so on.
Toolchain Example:
libstdc gets built well after its
gcc parent. I'm
GUESSING there's an app/library or two that are built between GCC and LibStdC which makes it necessary to separate things
in this fashion? Which ones? I don't know yet... I haven't really dug that deep. However, if I had a DEP: list, I'd know which BUILD TOOLS to load which we've already compiled --- OR, if a couple are missing, I'd know which ones NEED to be compiled, then I'd come back to the current one when they were done. This way, if I was building
mc for example, the system could toss out an error saying "Hey, dummy! I need
curses and
readline before I can do this... sit tight and I'll be back when those are done..."
Back to the LibStdC example... let's say there was a single dependency needed... and it could have been built before EITHER of our intended libraries. If its own DEP: list was already tended to, it could be placed higher up on the priority list and "out of the way" - and the build manager would be responsible for prioritizing extensions based on those DEPs.
@Paul_123: Another note after reading (and expanding) this thread, again, to be even more long-winded... one of the toolchain goals is JUST the compilation and creation of the extensions (build tools) which MAKE the toolchain possible. Any and all methods to create the initrd, for example, really should be separated into the core tools (which is another monster for the near future.) For right now, the v14 toolchain note file is perfect as I can disregard everything else until after all of the tools compile perfectly as separate scripts.
NOTE: The system that is being built assumes NOTHING UP FRONT. This project's first job is to kill off any and all running extensions to leave the system as fresh and clean as possible, so
everything has to be declared. Yes,
compiletc is a cheat but since it exists, no harm... no foul. Someday, however, I'd like to see everything listed on its own without macro extensions. Only the CORE remains (unless there are locked files) so we get a clean slate with EVERY build, allowing numerous builds with a guaranteed starting point and the DEP: lists are accurate for any operating system on (most) any platform with our BusyBox and inherent tools as the only (portable) dependencies.
As with TOOLCHAIN, the template's job is also to allow BUILD TOOLS (building extensions specifically to help create other ones, not necessarily creating TCZs for the repo.) Due to the fact that there are dozens of chain apps/libraries it may be necessary to "call it a day" 33% of the way through building the chain... creating
build extensions takes the place of /tools BUT similar to TCZ files, can be shut down and loaded fresh the next day with a dedicated partition to mount and a "guaranteed clean" TCL motto. (copy2fs mentality compared to squash mounting will possibly be required... but it's too soon to tell.)
The final stage of this project (PHASE 5) involves creating a client/server back-bone (like peer2peer networking, but focused on compilations and testing as opposed to file sharing.) We have about 40 Raspberry Pi units (thanks to a TCL member, we now have a RasPi-1 again!) and a dozen or two x86/64 systems which will be the starting point for this part of the project along with anyone else's machines out there who wish to participate by loaning us a thread or more similar to the VPS (Virtual Private Server) type of operation. This also allows us to test extensions on SO many more physical platforms for debugging where otherwise we wouldn't be able to "see for ourselves" the outcome of a build - or a failed one, in particular.
Example: We have a TCL user who is trying to use an older AMD Athlon mid-tower and an even older x86 Celeron laptop to run an extension we haven't supported for a good number of years (boinc) and though the extension seems to work perfectly fine on
my newer i686 workstation, it crashes on his. PHASE 5 will allow the user to send me an "ID" from his test machine allowing me to single out his specific machine and remotely compile some of the extensions in question on
his hardware, allowing me to gather hardware notes and build logs from his specific hardware. PHASE 5 is intended to be completely user controlled and if everything works as the theory predicts, we won't even have to ponder firewalls or routers as it'll be client -> web server managed and most of the time, non-interactive unless we have a situation like his.
As always, thoughts and opinions are welcome!
Take care, Peeps!
any potential ability to accept _donations_of_whatever_might_be_of_assistance.
Okay... how does this sound...
You place $1 USD in an envelope and mail it in. (other options would exist for non-US residents for supplies instead of dollars.)
You then find two friends who are willing to repeat the process and those two friends get two more friends each and so on!
YOU spend $1 and a few minutes of your time. What happens afterward is...
$0.80 of each dollar will be used to furnish computer and/or IoT hardware to children ages 5 to 16 (on average) in an introduction to computers, 3D Printing, IoT Development, Robotics and a few other topics that are being considered in a project called "IND001 INTRO DESIGN AND FABRICATION" which is in trials right now (starts Monday) in our local school district between grades 1 and 10. The school's current funding is dismal (which is expected in a trial run) and is only scheduled to run this 2024/25 school year if the public response isn't
above terrific. Elementary kids have "labs" during summer months, everyone else during the school year.
$0.12 of each dollar will be used to hopefully entice a few bigger names and companies to stop by and throw a mini "seminar" for the kids throughout the year (mostly to keep their costs to a minimum, not for anyone to think they're going to make it rich!
)
The remaining
$0.08 is planned for maintenance, fuel/shipping, supplies, etc.
If this gets enough attention and we're able to repeat it for 2025/26 we'll be bringing in a camera crew, getting local media involved, etc. so that we can create a curriculum out of the entire year which we'd put out there for the world to share in. Again, it's hoped to gain traction and if we're lucky, other schools across the planet will pick up on the program!
Welcome
FAQ
Downloads
Wiki
