Buildpet

discuss compiling applications for Puppy
Message
Author
User avatar
Tman
Posts: 808
Joined: Sat 22 Jan 2011, 21:39
Location: Toronto

Buildpet

#1 Post by Tman »

Hello,

When I first started compiling apps, I felt a sense of great satisfaction of being able to be able make pets from source files. But after some time, I realized that, with so many sources out there, it would be much, much more efficient to have some sort of automated build scripts do it all for you. Once you have created a build-script, then it should do everything for you, from downloading the source, configuring it, and converting into a pet.

So I started creating my own build-scripts which did the job, but then I discovered Iguleder's buildpkg system, which allowed for much smaller build-scripts, and also created smaller pets than my own system.

When I first tried it out, I was amazed, and delighted! :lol: Iguleder had done some fantastic work on this, and I could tell that he spent a lot of time creating the scripts. So the bulk of this project was already completed, thanks to Iguleder.

I took the buildpkg script and have adapted it so that it will create a suffix at the end of the pets. Also I have added a few bug fixes and some extra features. Newer scripts will have extra info sent to the /home/buildpet_info folder, or to /tmp/buildpet_info, if running without a savefile.

I also plan to add a grahical interface to this system, later on. After all this is complete, then I will periodically create and add build scripts to the repository.

I hope to end up with a large collection of build scripts so that eventually, a novice user will be able to load up any version of Puppy and be able to create pets from source files with a few clicks of the mouse .

Currently however, there is no GUI in place but using it from the terminal is not so difficult:

1) First you will need to install buildpet
2) load the devx sfs file. For drivers, the kernel-sources sfs must also be loaded
3) Open up a terminal emulator or exit to the console.
Example to build leafpad:

Code: Select all

buildpet /usr/share/buildpet/document/leafpad.bp
or

Code: Select all

cd /usr/share/buildpet/document
buildpet leafpad.bp
Done! That's it. The pets will end up in /root/my-pets. The only downside to this, is that for big apps, you will need a large savefile, since the sources will be extracted to the /root/my-pets folder. I may alter this in the future, but for now I just wanted to get it working right.
The only thing that the scripts will not do, is check for needed dependencies; But if a build fails to compile, there should be error messages that will tell you what dependencies are missing.

Download links are below.

Compilers
If you wish, you can post your configure options for apps that I haven't made scripts for. I can then test them, create new build-scripts and upload them to a repository.
Attachments
buildpet-0.6.pet
Early days buildpet with gui and Sept-12-2013 scripts
(89.6 KiB) Downloaded 1265 times
buildpet-scripts-Sept-12-2013.tar.gz
updated scripts; newer ones were created and tested on Slacko 5.5
(84.52 KiB) Downloaded 1188 times
Last edited by Tman on Fri 20 Sep 2013, 06:05, edited 3 times in total.

User avatar
pemasu
Posts: 5474
Joined: Wed 08 Jul 2009, 12:26
Location: Finland

#2 Post by pemasu »

Works. Thanks ! :D

User avatar
oldyeller
Posts: 889
Joined: Tue 15 Nov 2011, 14:26
Location: Alaska

#3 Post by oldyeller »

Hello Tman,
when I try and do tint2 or wbar I get permission denied.

Is there something else I need to do?


EDIT I saw what I did not do :lol: :lol: :lol: :lol:

I should have looked closer at the example you gave above.

This works really nice Thank you so much for this

Cheers

User avatar
sc0ttman
Posts: 2812
Joined: Wed 16 Sep 2009, 05:44
Location: UK

#4 Post by sc0ttman »

I have been making updates to buildpet, including

- auto tar up the source dir of svn/git downloads, then remove the source dir when not needed
- allow to change package versions in the build script (can now download 'pkg-latest.tar.gz', which might unpack the dir 'pkg-0.x.x' - now it will still work fine, with the right stuff in the build script [see jwm build script])
-added ability to auto-integrate with Pkg (my cli pkg manager) if its installed
- updated info in pop up message when installed
- more verbose error reporting
- added build scripts for: jwm (always builds latest version), easytag, audacious, xcb_proto, xcb_util, pekwm, freeciv , others ...
- fixed some buildscripts (xpad, others), needed `wget --no-check-certificate`

to see all build scripts available to compile, type the following in the terminal:

Code: Select all

find /usr/share/buildpet
A very small note for Akita users: cos of this,

Code: Select all

pkg --compile-pkg jwm
pkg --install jwm
etc
will be all you need to compile and install stuff from source in the next Akita :)
Attachments
buildpet_nogui-0.5.pet
(63.97 KiB) Downloaded 1362 times
[b][url=https://bit.ly/2KjtxoD]Pkg[/url], [url=https://bit.ly/2U6dzxV]mdsh[/url], [url=https://bit.ly/2G49OE8]Woofy[/url], [url=http://goo.gl/bzBU1]Akita[/url], [url=http://goo.gl/SO5ug]VLC-GTK[/url], [url=https://tiny.cc/c2hnfz]Search[/url][/b]

User avatar
Tman
Posts: 808
Joined: Sat 22 Jan 2011, 21:39
Location: Toronto

#5 Post by Tman »

sc0ttman wrote:I have been making updates to buildpet
Thanks, and good work, Sc0ttman! :)

simargl

#6 Post by simargl »

.
Last edited by simargl on Sun 01 Sep 2013, 15:29, edited 1 time in total.

gcmartin

Which PETs should I install.

#7 Post by gcmartin »

This appears to be a useful tool for one on my needs.

Which of the PETs is the most current for build scripts?

Thanks in advance

User avatar
Karl Godt
Posts: 4199
Joined: Sun 20 Jun 2010, 13:52
Location: Kiel,Germany

#8 Post by Karl Godt »

To me it is a bit of a children 's toy :
The need for these configuration files to download makes it unusable for me .
Almost everywhere I would need to adjust Tman's or iguleder's or Barry's configure options and version numbers and and http://paths .

The functions in the .bp files are basically the same everywhere .

Almost all paths aren't double quoted if weird chars or spaces in file names occur .

I think searching at packages.debian.org and go to the homepage , download it there , click to open it with xarchive , open a terminal and run ./configure ; make; new2dir make install would be as fast with better control while downloading .

*
PRO Buildpet :
The code is clean and nice to read for someone that knows how this all works .

User avatar
Tman
Posts: 808
Joined: Sat 22 Jan 2011, 21:39
Location: Toronto

Re: Which PETs should I install.

#9 Post by Tman »

gcmartin wrote:Which of the PETs is the most current for buildcripts?
I have added a newer tar.gz file in the first post. This is the newest that I have; sorry I don't have a listed of what I added. Also, a lot of the scripts were edited to download newer versions.
BUT... a lot of the newer scripts might not work right away on older pups, due to dependency issues... meaning you might need to update the dependencies first.
The testbed for my older scripts were on Solidpup 5.1.1B, while the newer ones I made were used on Slacko-5.5 when I was making Tinted Slacko 5.5

If you download Sc0ttman's latest Akita, he has some new scripts of his own in /usr/share/buildpet folder
Karl Godt wrote: I think searching at packages.debian.org and go to the homepage , download it there , click to open it with xarchive , open a terminal and run ./configure ; make; new2dir make install would be as fast with better control while downloading .
Perhaps it would be as fast, during the first time you do it, since the longest part is creating a proper .bp file.
But I think after you've got it configured the way you want, buildpet will be much faster AFTER the first time.. like when you want to build a new pet on a different version of Puppy

Also, a lot of newbies don't know how to "/.configure" and use new2dir... hell, I don't remember having used new2dir, myself.
Prior to buildpet, I started compiling with Amigo's src2pkg, but then I started doing it manually to learn that process a little better.
Buildpet is a system designed for noobs, and for Devs who compile the same apps for various Puppies/Puplets.

If you wanted to see buildpet in an even more user-friendly manner, check out Sc0ttman's Akita...he's got a gui for it in his package manager.
Karl Godt wrote:To me it is a bit of a children 's toy :
Contrary to what some forum members think; I am not a good Bash scripter.. I am more of a Bash hacker. My bash skills are not at your level; I do what I can.

User avatar
sc0ttman
Posts: 2812
Joined: Wed 16 Sep 2009, 05:44
Location: UK

#10 Post by sc0ttman »

Karl Godt wrote:everywhere I would need to adjust Tman's or iguleder's or Barry's configure options and version numbers and and http://paths .
Why? What adjustments need to be made for the downloads and compiles to work?

Or do you simply want to customise the buildscripts before compile? In which case, buildpet is not the issue.

..I am gonna come back to buildpet at some point and make it so that users can define the version they wanna compile direct from the command line...

And I don't see that it should be too hard to implement a dependency feature, where the deps are compiled first if not installed.. and i do agree that not using double quotes, just to make the code look nicer is not great, but URLs, package names and buildpet paths have no spaces..
Tman wrote:If you wanted to see buildpet in an even more user-friendly manner, check out Sc0ttman's Akita...he's got a gui for it in his package manager.
Not yet, next version ... Will be out fairly soon..

Also, I get an error trying to download buildpet-sep-22-2012.tar.gz..
[b][url=https://bit.ly/2KjtxoD]Pkg[/url], [url=https://bit.ly/2U6dzxV]mdsh[/url], [url=https://bit.ly/2G49OE8]Woofy[/url], [url=http://goo.gl/bzBU1]Akita[/url], [url=http://goo.gl/SO5ug]VLC-GTK[/url], [url=https://tiny.cc/c2hnfz]Search[/url][/b]

simargl8

#11 Post by simargl8 »

Tman,

buildpet is something Puppy Linux needs very much, for packaging efficiency,

and in 100% of other distributions using build script to make packages is a standard.

Too bad BKooler doesn't want to include it...

anikin
Posts: 994
Joined: Thu 10 May 2012, 06:16

#12 Post by anikin »

simargl8 wrote:Too bad BKooler doesn't want to include it...
Juvenile comments like this will hardly attract more users to your project.
They will rather alienate the remaining few, who are struggling to follow ... me thinks :(

User avatar
Karl Godt
Posts: 4199
Joined: Sun 20 Jun 2010, 13:52
Location: Kiel,Germany

#13 Post by Karl Godt »

That is a real heavy bunch of work to maintain 200+ separate package configuration files in BuildingBlock for example .

I could think of ONE huge file that contains VARIABLES ie

PATCH_NAME=patch
PATCH_VER=2.6.1
PATCH_REV=1
PATCH_DESC='Patch applying tool'
PATCH_CATEG=BuildingBlock
PATCH_DEPS=
PATCH_HOME=ftp.gnu.org/gnu
PATCH_CONFIGURE_OPTS=
PATCH_CFLAGS=
PATCH_Libs=
PATCH_LDFLAGS=

As a crude example I have hacked patch.bp , that includes code that should be somewhere else plus the download function to test for xz bz2 gz :

Code: Select all

#!/bin/bash

exit_ (){ ## $1 wanted exitcode-# $* Additional Message
	case $1 in
	0) echo "Exit status is $1 .";;
	*) echo "Error $1 occurred :";;
	esac
	RV=$1;shift
	echo "$*"
	exit $RV
}

[ "$*" ] || exit_ 1 "Need Parameter (short pkg name ie abiword)."

echo $LINENO

PATCH_NAME=patch
PATCH_VER=2.6.1
PATCH_REV=1
PATCH_DESC='Patch applying tool'
PATCH_CATEG=BuildingBlock
PATCH_DEPS=
PATCH_HOME=ftp.gnu.org/gnu
PATCH_CONFIGURE_OPTS=
PATCH_CFLAGS=
PATCH_Libs=
PATCH_LDFLAGS=

echo $LINENO

grep -i "$1" "$0" >/tmp/buildpet."$1" || exit_ 1 "No such '$1' pkg for this program."

HOME_PAGE=`echo $(grep -m1 -i "^${1}_HOME" /tmp/buildpet."$1" | cut -f2 -d=)`
[ "$HOME_PAGE" ] || exit_ 2 "HOME_PAGE Variable Empty '$HOME_PAGE'."

NAME=`echo $(grep -m1 -i "^${1}_NAME" /tmp/buildpet."$1" | cut -f2 -d=)`

VER=`echo $(grep -m1 -i "^${1}_VER" /tmp/buildpet."$1" | cut -f2 -d=)`

echo $LINENO

download() {
	# download the sources
	for ext in xz bz2 gz ; do
	[ -f "${NAME}-${VER}.tar.$ext" ] && return 0
	wget --spider http://$HOME_PAGE/$NAME/${NAME}-${VER}.tar.$ext || SPIDER_ERR=$((SPIDER_ERR+1))
	[ $? = 0 ] && { wget http://$HOME_PAGE/$NAME/${NAME}-${VER}.tar.$ext && break; }
	done
	[ -f "${NAME}-${VER}.tar.$ext" ] && return 0
	[ "$SPIDER_ERR" = 3 ] && echo "http:://$HOME_PAGE/$NAME/${NAME}-${VER}.tar.* apparently Not Found on that Server."
	return 1
}
echo $LINENO
download;echo $?
echo $LINENO

simargl8

#14 Post by simargl8 »

Code: Select all

name=geany
version=1.23
release=1
source=(http://download.geany.org/$name-$version.tar.bz2)

build () {
  cd $name-$version

  ./configure --prefix=/usr \
              --mandir=/usr/man \
              --enable-plugins

  make
  make DESTDIR=$PKG install
  rm -rf $PKG/usr/share/{doc,locale}
}
CRUX Linux Pkgfile http://crux.nu/ports/crux-3.0/contrib/geany/Pkgfile

Simple and beautiful. :D

gcmartin

Buildpet is it now v0.4 or v0.5?

#15 Post by gcmartin »

Hi @sc0ttman. Nice to see this tool and your ideas come together along with all the others, here.

What is the chance that an elementary version of this tool could become the foundation for a GUI for newbie use?

The effort and the terminal use could become a foundation for PET creations and an instructional for newbies.

Idea/not?

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#16 Post by amigo »

@simargl8 -the crux 'build' functions are similar to several other build systems(arch PKGBUILD, BSD pkgsrc, others). The main problem with using just one or two functions is this: all other operations are done according to some default set of rules -thus not allowing for further intervention in these operations. What if those default operations remove or add files to the package which you do/don't want/need?

The other extreme is a debian 'rules' file, where you have 58 debianhelper (dh_*) functions which must be either added or commented out. The problem here is remembering all those instructions. RPM *.spec files have a similar problem -lots of macros, but specfiles offer a bit more flexibility than debian rules files.

There are two problems which affect nearly every build-system out there. 1) They all require some sort of specfile/recipe/spell/rules file for any and every build -even when only the default settings are used. 2) They have no way of protecting the system which is being used to build on -for instance when there is no DESTDIR support. In such cases, the 'make install' (or similar) command happily installs files to the real root, spamming your system.

While the debian CDBS lets you use a minimal rules file of only three lines, with no package-specific info besides the name and version, it does still require you to create that file, as well as(at least) a 'control' file and a 'copyright' file.

Karl Godt is correct in opining that having to endlessly repeat common config settings in every build script is a useless pain. The same can be said of *.SlackBuild scripts which contain many lines of code which are simply repeated in every script. Having a lot of redundant lines in a true build-script or recipe file, means that it is harder to quickly see how this build differs from any other build.

Everything should be kept as simple as possible -but no simpler. There are two main sides to consider when building a package/bundle/fsimage. The first consideration is being able to successfully and repeatably produce/compile/assemble the actual content which should be packaged. The second side is how to arrange the content so that it conforms to the package specifications. Meeting the expectations of the targeted system and package manager is pretty easy -if the specifications are complete enough. Getting things to build in the first place is much harder because there are always unknowns -any source of content could require any number of methods of configuration/compilation/assembly.

In both cases, there may be special needs which cannot be satisfied with just default routines -no matter how smart they are. In fact, there are rarely packages which don't need some sort of tweaks which must be work in combination with, or instead of any default routines. But, on the other hand, one shouldn't have to manually write each and every step needed.

Any packaging-building scheme which does not provide repeatability of the operation is absolutely non-maintainable. Any packaging scheme which cannot reliably pinpoint the source of any content and the way to create/obtain it, will always lead to either 'dependency hell' or inconsistent results -one should never think that running programs produced on OS 'A', will work with libraries produced on OS 'B'. Hence, a 'pick and choose' approach will never be consistently up to the job.

@gcmartin, I'm interested to know what sort of a GUI you think would work for creating packages? How do you imagine that it would work? In how many steps should the user be compelled to intervene(provide input or make choices). And in how many times/places should the option to do so exist? Long ago, big_bass worked some on creating a GUI for src2pkg -actually a GUI just for setting up the configuration file. Other src2pkg users sometimes expressed a desire for a GUI -but I could never figure out how a GUI would make things any simpler. I did finally implement an AppDir which provides for drag-n-drop functionality -even simpler than a GUI. You simply drop a tarball on the icon and a package gets created -or a recipe for a package which can then be customized and dropped on the icon to perform the build.

The problem is that creating content and then packaging it requires the use of many tools -at least 50 different programs might get used for even a simple build. And each of these programs (all CLI, mind you), have any number of different options. A GUI which offered any sort of flexibility as front-end for all these programs would simply be a mess! The user would be presented with many tabs/windows of choices to make and no way of knowing which ones must be set before building -when in fact, many programs can be successfully configured, compiled and packaged without any package-specific information other than the name of the sources.

I still can't imagine anything easier than this:
src2pkg URL(or path to tarball)
or:
drop an already-downloaded tarball onto an icon

For any package with special needs, the wealth of options which would even partially cover those needs is way beyond being helped with a GUI front-end -maybe having a whole set of GUI's would make things easier. But, even if possible, any build method which always requires human input is unsuited for production use. Any special needs should always be encapsulated in some sort of non-interactive process in order to 'prove' the repeatability of the build. Please don't let this paragraph stop you from thinking about how it might look/work to have a GUI -I really am interested to know.

User avatar
sc0ttman
Posts: 2812
Joined: Wed 16 Sep 2009, 05:44
Location: UK

Re: Buildpet is it now v0.4 or v0.5?

#17 Post by sc0ttman »

gcmartin wrote:What is the chance that an elementary version of this tool could become the foundation for a GUI for newbie use?
here's a very basic gui... very basic..

if it doesnt work ur on ur own.. at least for now.. see amigos caveats above... although it includes the option to edit the buildscript yo choose..
Attachments
buildpetui.tar.gz
unzip, run the script..
(1.44 KiB) Downloaded 963 times
[b][url=https://bit.ly/2KjtxoD]Pkg[/url], [url=https://bit.ly/2U6dzxV]mdsh[/url], [url=https://bit.ly/2G49OE8]Woofy[/url], [url=http://goo.gl/bzBU1]Akita[/url], [url=http://goo.gl/SO5ug]VLC-GTK[/url], [url=https://tiny.cc/c2hnfz]Search[/url][/b]

gcmartin

#18 Post by gcmartin »

BuildPetUI
Should I have the DEVX loaded when executing the script? or is a parm/filename required?

Code: Select all

# buildpetui 
/root/my-applications/bin/buildpetui: line 58: syntax error near unexpected token `>'
/root/my-applications/bin/buildpetui: line 58: `    			buildpet "$BFILE" &>>$PKGLOG && echo "Finished." >> $PKGLOG'
Thanks @Sc0ttman

User avatar
sc0ttman
Posts: 2812
Joined: Wed 16 Sep 2009, 05:44
Location: UK

#19 Post by sc0ttman »

gcmartin wrote:BuildPetUI
Should I have the DEVX loaded when executing the script? or is a parm/filename required?

Code: Select all

# buildpetui 
/root/my-applications/bin/buildpetui: line 58: syntax error near unexpected token `>'
/root/my-applications/bin/buildpetui: line 58: `    			buildpet "$BFILE" &>>$PKGLOG && echo "Finished." >> $PKGLOG'
Thanks @Sc0ttman
change &>>$PKGLOG to just >>$PKGLOG on line 58.. damn bash 3/4 incompatibilities... (i think)..
.. note that's not a proper fix as such, but should work ok..
[b][url=https://bit.ly/2KjtxoD]Pkg[/url], [url=https://bit.ly/2U6dzxV]mdsh[/url], [url=https://bit.ly/2G49OE8]Woofy[/url], [url=http://goo.gl/bzBU1]Akita[/url], [url=http://goo.gl/SO5ug]VLC-GTK[/url], [url=https://tiny.cc/c2hnfz]Search[/url][/b]

User avatar
Tman
Posts: 808
Joined: Sat 22 Jan 2011, 21:39
Location: Toronto

#20 Post by Tman »

Thanks all for the input.
I have packaged the gui along with buildpet_nogui-0.5, plus the Sept-12-2013 scripts into buildpet-0.6.pet. The download link is on the first post.

It is still early days. Thanks, sc0ttman for the help.. I defer version 0.7 to you, when you have improved the gui. (a search function would be nice) :wink:

Amigo has some very good and valid points.

Redundant codes, such as extracting the tar files could be moved from the .bp scripts, and into /usr/bin/buildpet
Some smart code could detect if it's .gz , bz2, or xz and extract the files accordingly. I would also like buildpet to ask the user to build the dependencies first, but don't know as of yet how to implement it.

Maintaining all of the scripts would be too much for one person. It would be nice to have a group of maintainers, but I don't foresee that happening anytime soon ... so it is up to the individual using the scripts to update them to bleeding-edge versions, if that is what they wish... I only update apps which I actually compile, and for the ones which I don't, I just leave them as is. Often, just updating the version number portion of the script will do the trick.

No system is perfect, but I think it is better than having no build system at all.

@simargl,
thanks for the support, but please try not to insult Barry Kauler.
After all, he is the genuis and visionary who gave us PuppyLinux, without which, none of my Puplets, your Puppy forks and this entire forum would have existed.

Thanks Karl and gcmartin for the input. It's late here.. brain getting fuzzy.. must sleep.. zz zz zz

Post Reply