Ok let me ask the question: would be capable to provide description of SlackbuildScript class? Say for python. So every class instance is concrete build script. If yes this is what I am looking for. Such description however would be inconvenient to work directly with. Problem is can't do it myself. If I want to reach end goal description has to be supported by others as more or less sensible. The only way I think is to people get involved. Ok you think there is 'no way' - lets try from the beginning and start the sentence with 'maybe'.

Have a look at mkslack: https://slackbuilds.org/repository/14.2/system/mkslack/, a SlackBuild generator and at Alien's SlackBuild Toolkit http://alien.slackbook.org/AST/

1 members found this post helpful.

src2pkg takes a source tarball and generates a package almost all the time.

Generally speaking if a slackbuild doesn't exist for something I want to add then I will just go the ./configure && make && make install route, with the added steps of setting destdir and using makepkg, as outlined here: https://docs.slackware.com/howtos:sl...ding_a_package

It's a simple enough option and doesn't require writing a bash script, although the user will still have to understand what they're doing. Of course I build such a package for my system only. I know it's not the automated solution you would like but it works.

You can build from source or you can repackage some other distribution's package.

If you build from source, there are multiple build frameworks (autotools, scons, cmake, and others) that normally are invoked using different commands. Those source builds also have optional and/or required dependencies.

If you build from some other distribution's package, you need to know how that distribution's packages can be open and information extracted.


So, a parent class for source builds and a parent class for repackage builds. Subclasses for the various source build frameworks. Subclasses for the various distribution repackaging types.

EDIT: There are packages that require multiple source archives to be built as well; that's another addition to your source build class tree.

Someone please close this nonsensical thread.

1 members found this post helpful.

It's not entirely nonsensical but I believe it to be much more work to implement than the OP realizes. Since I do not believe that English is is OP's native tongue, I'm willing to spend some energy to attempt to understand what the OP means.

Interesting idea. OP, why not try prototyping this with M4? Kindly avoid the GNU extensions for compatibility reasons.

/me runs

Honestly I feel like reading this thread was 10 minutes of my life I'll never get back.

Could we have just one darn thing not done with json.

Adding another layer, I guess you're free to do it if that's what you like but if I wanted extraneous layers I'd go back to using debian. Not interesting to me.

2 members found this post helpful.

I might be more sympathetic if the OP would have said, here look what I did instead of asking someone to do it for them. Even if their native language is not English and the result was terrible because at least then they would have put fourth the effort.

And then, to say that they don't want to learn bash (which I hope that they already know, and is just trying to benefit a new user) when a SlackBuild is nothing more than a bash script is comical.

I've pointed out to the OP that there's already something out there that works most of the time: src2pkg.

If the OP looked at Gentoo's ebuild setup, he/she/it would learn how much infrastructure is required to get something data driven to work (most of the time).

I'm not sure that you'd like XML controlled by a schema any better.

(I've written schemas for XML that were used by a build system to create SNMP alarms and logging classes. I happen to like XML, but I've found myself to be in the minority.)

1 members found this post helpful.

You are not alone.

1 members found this post helpful.

Negative, there is no way. Of course it's theoretically possible to build some abstraction layer on top of SlackBuilds: you could start for example with generators for common build systems (take a look at the template links that have been provided to you, and abstract out the boilerplate stuff).

What I am saying is that it is simply not enough to say "Hey, just explain to me what a SlackBuild is in words, and I'll create an abstraction layer capable of generating any given SlackBuild". You're more than welcome to try, but familiarity with a range of SlackBuilds and build systems is a basic requirement. You cannot create an (elegant/workable/correct) abstraction of something that you don't understand in the first place. Argue otherwise if you like, but in the end you're going to have to demonstrate some work/code if you want people to take you seriously.

SBo: a ports-like system for Slackware Linux

Am I too late?