Blocks Base V1.0.1.1 HYBRID WiN MacOSX R2R
Sofie Kovalcheck
While the primary platform for the RBT project is predominantlythe Linux platform, whenever possible support for other platformswill be added as well. In fact, it is a secondary goal for the RBT projectto support all platforms ruby is able to run on in the long term. Howrealistic it is to reach that goal is another matter, but as a goal RBTwill eventually try to support as many different operating systems aspossible, provided that ruby can run on such a system.
Ideally, in the future, we could reach a state where we can test theRBT suite on less commonly used systems as well, such as HaikuOSor ReactOS to name only a few here. And, of course, the morepopular ones such as OSX or Microsoft's Windows suite as well, naturally.Windows is the second operating system that RBT will support, by theway; it is less well-tested than the Linux-specific code of theRBT project.
This is also another reason why the --user-install option is better,in my opinion - you don't have to guess where the executableswill reside; they are just in the home directory, somewhere there.And you can move them from there to any other location anyway,or use symlinks and/or aliases via your shell to setupthe system how you want it to be. Or, use the ruby codedirectly - after all you can create your own executables, sincethat is precisely what all gems do anyway in their correspondingbin/ subdirectory.
Since gems are also downloaded locally, and then available asa .gem file, other users can easily install these gems into theirhome directory as well, without depending on a global installation.This may be especially useful in environments where you arerestricted, such as at a campus/university environment.
On windows, if you plan to upgrade the rbt gem, I recommend to firstuninstall all old rbt gems. While this is, strictly speaking,not really necessary, I found that it may work better if old gemsare removed - at the least on windows. There I manually remove thedirectory where the old ruby stores gems. Again, this is probablynot strictly necessary, but I found that this works better in thelong run.
If all goes well then the above tarball, the file nameevince-42.3.tar.xz, will be downloaded (unless italready exists locally), extracted, and then compiled.It all goes well the user will then have the specifiedversion of evince installed, compiled from source.
It should never be more complicated than that, forwell-behaving programs. At the least in theory;in practice you can imagine that some things may goawry or not work, but this is where rbt willalso try to be of help, in order to resolve suchproblems.
Note that while the primary focus is on compilingsource code as-is, a secondary focus is to allowinstallation from a binary source, as well as tosupport different package managers, similar to thefpm gem ( ).
What does this mean? This means that the RBT projectwill try to be of help to people who wish tomanage the software on their respective computersystems in general. This may even extend towards otherprogramming languages, be it python, java, C/C++,shell scripts - you name it.
Another "higher" meta-goal that follows this vision isto integrate tasks that are typicall done via apackage manager. Support for this within RBT itselfis presently (2024) still fairly minimal. Do not expect RBTto become a fully fledged package manager right now; but,perhaps this use case may be covered one day in the future.Until then singular aspects found in different packagemanagers may be included into the RBT suite as well.
Yet another goal for the RBT project is to provideall the raw data used for managing all programson a Linux Distribution or another Operatingsystem. As one example: (almost) all programs that areregistered in the RBT suite have a remote URL registered -see the evince example above.
The data is primarily stored in various individual cookbook.yml files. These .yml files can be turned into a SQLdataset. This will at one point in time probably becomethe default way for users to interact with the datasetmade available by the RBT project. In the past, sinceas of August 2022, it even was recommended to makeuse of a SQL database, but I no longer recommend thisfor now; many things have to be polished in the RBTproject before we can fully transition into a SQLdatabase. For now, prefer to make use of the various.yml files that are distributed. See elsewherein this document more information pertaining to this.
Although this approach is very easy to remember and apply, it doeslead to a few issues sometimes. For instance, if two remoteprojects have the same name, then only one can be registered inthe RBT project, using that simple naming scheme. The workaroundI use in this case - and let me assure you it happens very,very rarely only - is to change the name of the .yml file a bit,such as perlsdl.yml for the perl wrapper over sdl.
I have used RBT specifically to help me in my attempts toboostrap a LFS/BLFS (Linux from Scratch / Beyond Linux fromScratch) system, so this is an additional use case (and goal) forthe RBT suite as well.
I think that the RBT suite does have some real value here - orthere. For this I would like to coin the phrase "from zeroto hero" - which means to bootstrap and create a Linuxsystem that can be burned on a DVD or simply put ona USB device. This is not yet working flawlessly, but it ison the TODO list as well: to support LFS/BLFS builds fromscratch (aka from zero).
For example, one part of RBT can be used to autogenerate completion filesfor bash and zsh; I use this to more easily compile programs, such asby typing "ry autom", to become the very same as "ry automake". Thisthus saves me a few keystrokes on the keyboard.
Another script, also part of the RBT suite, can modify Makefiles andchange the prefix in that file, without me having to remember the awkwardsyntax make uses when trying to override the default prefix inuse. These are examples for such "toolkit" scripts in RBT, so the overallgoal for the RBT suite is to help in regards to such use cases. Theprimary use case remains on compiling source code as-is, though.
We could continue this listing here, but I think the basic point wasalready pointed out now. If you look at the RBT suite from a widerperspective, RBT attempts to be a swiss army knife forcompilation/installation of software projects. The focus herelies on hands-on use - it is a toolset project and has tooffer code/functionality that helps solve certain computer-relatedtasks.
There were various smaller reasons - a few bugs, a few things thathave to be improved, and so forth. Some of these bugs were veryold, and I haven't gotten around to fixing them, so this providedan opportunity here.
But, the biggest reason for the rewrite was something else: I wantedto transition into well-defined actions for the RBT project.Other subsections of this document will explain the rationalebehind well-defined actions more; suffice to say that Iwanted to have all important, actionable activities tied togetherand have them be usable via the commandline as well. This wouldallow me to tap into the RBT project without having to rely solely onclasses and methods - instead I can use actions to do individual steps,such as symlinking files, copying files, performing post-installationsteps and so forth. If I want to apply some patches automatically thenI could do so too, such as:
Yes, there is not much difference between these two variants, but the aboveentry-point, via rbt_action, allows us to think in terms of actions first,rather than the program name first. Plus, I could provide specificindividual actions in a specific order, which I can not easily do viacommandline --flags.
That's right - you may only need a small subset of the RBT suite, andthat's ok. The RBT suite attempts to cover different use cases andneeds, so it is highly likely that not every user needs to use allof the RBT suite.
However had, even if a user does not intend to install or compile anythingthrough RBT, many different programs are registered in this project,which may be of (indirect) help in some other ways. For instance, if auser desires to determine which particular binary on a given Linux systembelongs to which particular application, or if the user intends toimplement a package manager on his or her own, then the RBT suite maybe useful, as it allows such potential users to query this through theRBT suite.
The dataset for the standalone programs is available under the namespaceRBT::Cookbooks. For a list of all registered programs, you cansimply query the toplevel-method called RBT.available_programs?.
Related to this question of "How do users benefit from the RBT suite?",one part of the RBT suite deals with statistics. Support for this issomewhat minimalistic right now, but will be extended in the future. One scriptreports some statistics, such as how many of the registered projects dependon cmake, or meson, or GNU configure, or a Makefil and so forth. You canquery their percentage value, and thus gain a little insight into howdifferent projects make use of which particular build tool. That is an examplefor statistical information.
This part about statistics will be slowly extended over the coming years, butit is not the primary use case for the RBT suite - just something that I foundto be interesting to know, how many different projects out there depend onwhich compilation strategy, and how this may change over the years. Presently,in the year 2024, many projects still depend on GNU autoconfigure/configure.cmake comes second, meson/ninja comes third. I found that monitoring the riseof meson/ninja to be quite interesting, and I expect that this trend willcontinue. Of course the subset that is registered in RBT is not thefull picture, so the statistics are only valid in regards tothe RBT suite itself. Globally we may see a completely different picture,but the statistics shown by RBT are correct when it comes to the programsregistered in the RBT suite.
7fc3f7cf58