Years of software development has taught me there are three types of abstractions.

1)
Complex well thought out ones that grant uniformity (map things to language semantics and make them orthogonal to other constructs) which generally don't hide complexity

2)
Simplifications that are well thought out covering the most common usage and don't attempt deal with corner cases. An example here might be an ORM it will provide you with a simple reliable way to do do 99% of the CRUD operations your application needs; you still write a SQL statement to handle that super complex report.

3)
Naive abstractions where the author did not understand or appreciate the problem domain, does not realize how limiting their solution is and how frequently user will run into the walls and does not realize their solution forces really kludgey workarounds because they never understood the right way to do the job in the first place... (This sadly is the most common form)


What the OP does not seem to understand is that Slackbuilds are solving a very complex problem. Here is your natural language description of what Slackbuild is: "Its a non-interactive script that builds a slackware package for software or shared data files from some number of file or URL based inputs." Good luck writing an abstraction for that its to big a domain. The best you can do is some templating like the really excellent work Alien Bob has already done.

As much as the Rubists and Pythonistas want to believe otherwise you can't boil everything in computing down to a single call to Universe.makeMeASandwhich(). This only works as long as everyone wants a PB&J. It all comes apart the moment someone wants a grilled cheese and god help you if someone orders the Monte Cristo. While they all still share some common features, suddenly we are not even trying to spread things on the same side of the bread. The sensible programmer will go back the drawing board here accepting complex problems require complex solutions and start creating separate procedures. The typical code monkey who does not actually know much about the wide world of sandwich arts will start solving their new problem. Pretty soon they are doing things like; grill(makeMeASandwich({pblevel=>0; jellytype=>:butter}).invert().addCheese(type=:cheddar)) trying to convince themselves this is sensible and clever.

So here back to the OPs objectives. Either back away and accept that a Bash probably is the right level of abstraction for constructing SlackBuilds -or- go the (2) route and restrict the domain. You could probably make a system that handles creating SlackBuild for say applications that start as source using gnu/autotools. You could probably parse the output of ./configure and generate a JSON blob with all the option parameters, and create a script from there. The thing is by the time you specify what you want those to be you could have just put configure --option=blah ... into Alien Bob's template and in about the same amount of time. So we are back to why bother here. Not at all sure what their is to gain..

6 members found this post helpful.

Possibly Windows and Apple are claiming that space. With, what they call, their 'user-friendliness'. In principle I would not tempt to cater for 'Don't want learners' as even running the simple 'normal language' command you have in mind will become problematic. This because the output, a novel program to run on their device, might already be too difficult a concept. Catering for those users, would in the end boil down to a procedure that goes like installing stuff on a smart phone, triggered by update alerts and pressing a lot of 'accept' keys and there you go; all your stuff ready for grabs by data-hungry companies (as the 'Don't want learner' might not want to be aware that some default settings are best turned off immediately). Nowadays, out of self-protection, you have to learn the strength and weaknesses of your tool, to which you could handover a lot of personal information.

In the end I think the availability of bash and things like Slackbuilds - which you can easily adapt for your own installs as they just harness the 'configure/make/install' sequence to obtain a controllable item, a package that can easily be installed/removed from a system - provides a lot of power to users. Learning to use those tools provides (a feeling of) control over your stuff that is lacking when running something like Windows or mobile phone apps.

Don't want learners might best be helped by being encouraged to learn something about their system.

Maybe I have taken above expression of the OP too literally; Maybe he has 'Cannot learners' in mind, who need a very simplistic interface in order to use their system in the first place. That would involve accessibility issues.

Before all these fancy packaging and build systems came along, one would simply type "make install" and it was as simple as that. ¹

How's that for "free language abstraction"?

----
¹ assuming all needed libraries were already installed of course.

+1 for everything here.

a SlackBuild is just a file name for a number of scripts that have many similarities, but you could build a Slackware _package_ (which is the real purpose here, surely?) using any tool you fancied, as long as the archive contained some specific files in a certain format an so on.
For example, there's this lovely "slacktrack" tool that takes a commandline switch:
In my mind, if someone doesn't know enough to edit some bash templates, but is going to read the instructions about how to build the software and in doing so, uses "tar", vim, whatever - even if it's literally ./configure; make install then that's not a great leap further to the most basic "SlackBuild" script there is.

But if you have a complex piece of software that actually requires lots of post or pre-processing in order to build a package of it, when you think about it, you're not using "bash" to do this, but bash is simply fork()ing a set of other tools when you hit ENTER. A bash script is simply a way to save you doing it by hand once again.

I cannot see a purpose to consider any such abstraction from these basic realities, and I'd see it as a retrograde step if one were to be made.
Unless of course you just fancied hacking on something to see what you could do. That's an entirely different thing! ;-)

1 members found this post helpful.

3 members found this post helpful.

Who is sudo?

2 members found this post helpful.

Here's an initial prototype. Hope y'all find it to be of use.

free_language_compilation.m4
SlackBuild-free-language.in

1 members found this post helpful.

Maybe you can start by looking some complex .SlackBuild files, you will notice that there are a lot of dirty tricks that are needed to build them: broken dependencies that have to be fixed, system incompatibilities, libraries version incompatibilities, temporal experimental features, bugs to be patched, files that have to be parsed to decide how/what to patch/compile/link, etc. Look for example:
virtualbox https://slackbuilds.org/slackbuilds/...box.SlackBuild
palemoonhttps://slackbuilds.org/slackbuilds/...oon.SlackBuild
qt5 https://slackbuilds.org/slackbuilds/...qt5.SlackBuild
LibreOffice https://slackbuilds.org/slackbuilds/...ice.SlackBuild

There are so many special cases, because every package is a different world. Many are well designed to just ./configure ; make ; make install, but often that is not the case. Some packages require a lot of experience/knowledge to create the build script.

Trying to abstract dirty tricks would be a nightmare.

"Everything should be made as simple as possible, but not simpler."
- A. Einstein

1 members found this post helpful.

I see we really need to go hard but this will make you feel stupid. But problem is if something is not possible for you it does mean it is not possible at all. First off I was rethinking what I imagine to reach: script by itself is not important. There is textual description and there is a parser which translate this into executable script - what literally is inside script is not important - system is not aimed at creating scripts - but building software. In other words - different parser can provide different scripts - yet these scripts should be functionally equivalent. Say someone who is creating such parser say does not like particularly sbo - for some reason. The scripts generated by its own parser are textually different and they do not follow the template for sbo scripts. Having parser on several instances it is enough to share textual descriptions instead of scripts. Scripts are locally based and never archived - or it is explicitly requested. So where to start? From vocabulary used by scripts, say
these are lexical elements, now it is needed to go trough all scripts and vocabulary is ready. Now I think we can play a little game: how many words do you think vocabulary for all scripts would contain? Now let see there are things like CAPSNAME, $CAPSNAME, name, --name, \(, and so on. Now we do statistic - dictionary. Grab word from vocabulary look for how many scripts contain this word. If many then supposedly the word should be considered required. At next stage semantic is needed: what these words are stand for? CAPSNAME: variable, $CAPSNAME: reference, name: command, command option. People here said about great of number of compile option flags. Ok.Once vocabulary will be created we will see how many in reality there are option flags. I mean if existed sbo script provided number of options are considered to be sufficient then based on this scheme also should be considered sufficient. Don't ask me to create thing better than those which exists already. Because you ask the same who create scripts for better solution.

Exactly. the shell-script is the easy part in all this. Collecting the right set of patches and choosing the right set of build options is the difficult part.

Abstraction would not aid the unskilled, and would only be an additional layer to learn for the skilled.

3 members found this post helpful.

Ok, I won't.

As far as I can tell, no one has asked you to do anything. You have asked us to do a lot of things for you. That's not how software gets developed. If you think this is a good idea, just go ahead and start doing it. I really don't understand why you are hanging around this thread arguing about it. Put up or shut up, as they say.

@igadoter
Can you explain a real life scenario where you would see this project used and who would use it? Power users, developers or system admins?

Also can you share a mock version of a script you imagine this to be like?

1 members found this post helpful.

I asked for free language description of sbo script. Nothing really precise, adequate, just in own words. Do you think this is lot of things? But as usually thread diverged.

I don't really understand what you request or suggest, and other's answers make me think I am not alone.

If you provide as an example at least the beginning of a free language description of a very simple SlackBuild, maybe that would help me and others to actually understand what you want.

1 members found this post helpful.