Buildpet

discuss compiling applications for Puppy
Message
Author
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

simargl8

#21 Post by simargl8 »

Tried buildpet-0.6 and for a test successfully built nano pet package in alphaos, system without pet package manager and any of other pet building tools.

Some problems to report:
- sh: line 51: defaulttexteditor: command not found
To edit buildscript instead of defaulttexteditor, you could use EDITOR environment variable, to be compatible with more than just puppy systems

- when buildpetui is started it shows this

Code: Select all

[root@alphaos Downloads]# buildpetui
/usr/share/buildpet/buildingblock/zlib.bp: line 2: usage:: command not found
/usr/share/buildpet/buildingblock/zlib.bp: line 3: configure: command not found
/usr/share/buildpet/buildingblock/zlib.bp: line 4: [--static]: command not found
/usr/share/buildpet/buildingblock/zlib.bp: line 5: [--includedir=INCLUDEDIR]: command not found
- other window that shows package building progress doesn't scroll automatically

simargl8

#22 Post by simargl8 »

This thing needs to get more attention, if I made those scripts I'd start thread under Puppy projects, and add github or mercurial repository, so others could contribute. A bit more simplification of the build script, improved gui and this could be standard way of making packages for Puppy Linux. Then one more thing is to add information about system where pet package is built, so everyone would know where it will work.

simargl8

#23 Post by simargl8 »

Noticed this on Arch forum...
ahcaliskan wrote:Cheflex is a package manager written in Bash. It is designed to be as
simple as possible. I like the simplicity of makepkg and it inspired me a lot.
.....................
https://bbs.archlinux.org/viewtopic.php?id=162727
http://www.selflex.org/cheflex/

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

#24 Post by Tman »

hi simargl,

Your points are duly noted. I think I will leave the gui building to sc0ttman and his superior skills with gtkdialog. ( if that's okay with you sc0ttman? ).

I think for now, I will just keep this project in this thread, since it's easier to maintain a higher place on the post list in the Compiling section than in the Puppy Projects section. As for github.. mabye at a later time, when I find the motivation to set it a up ( I've haven't registered for an account there yet ).

Thanks for the links to cheflex. The concept is similiar to buildpet. Our scripts cannot be so simplified becuase we need to create pet packages after the installation, but I will take a look at the code and see what usefull parts I can transfer to /usr/bin/buildpet and /usr/share/builpet/buildpet.profile.

Please note that I am juggling other Puppy projects, as well as non-Linux related things in my life, so be patient with me, if the progress is not going as fast as you would like.

simargl8

#25 Post by simargl8 »

I'm not too much interested in buildpet, simply because I use my alphaos system with pacman
package manager, only I'm sure scripts you're making are essential part of any Linux system,
and also Puppy Linux, so users if competent enough to help you should really do that.

note this all please duly or whatever.

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

#26 Post by anikin »

Hi Tman,
Many thanks to you for the scripts, they do work!
I have setup my own cflags and ran a few test builds. The first one was Geany, I've had two versions of it actually - the stock one and the latest. Both compiled OK, except that I can't make them as small as Barry's. Then I ran jwm.bp, all went well - flags, compile options, the only insignificant glitch is that there's no "jwm" in the final pet package. I say insignificant, because I get the same result if I compile it manually as "new2dir make install." Don't know, maybe it gets cut off as result of strip? If I do just "make install" manually, it does install itself. Can you please, have a look at this particular script? Something's wrong with it. The install path points to usr/local/bin, making it usr/bin doesn't change the outcome. One thing I'd like to have in the scripts is the final output as a directory structure, not a pet. Will you consider such an option?
And here's a tiny spelling wrinkle, that needs to be corrected in pinstall.sh,
change this:
"A many 'build scripts' are already included in /usr/share/buildpet/.
You can write you own and add them there as well."
to:
"Many 'build scripts' are already included in /usr/share/buildpet/.
You can write your own and add them there as well."

Thank you again and everyone who has contributed to this great effort.

.

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

#27 Post by Tman »

simargl,
Duly noted :P (teasing)
By the way, I tested Alpha OS. It's nice, and it appears we have similiar taste preferences in Desktop appearances. Pekwm looks pretty good as well, but I don't know if it has something similar to obconf.

anikan,
Which version of Puppy did you try to compile JWM in? The reason why I am asking, is becuase, right after reading your post I compiled JWM with buildpet on Pemasu's upup Raring 3.9.9 (which I plan to make a derivative on), and it appears to be fine.. my pet contains /usr/bin/jwm.

As for having buildpet building to a directory structure, you are in luck... buildpet already does that. However those directory structures get erased once the pets are built. To keep those directory structures, edit /usr/bin/buildpet and add find the line near the end of the script that says the following:

Code: Select all

rm -rf $PKG_FILE_NAME
add a # symbol to the start of that line, and you're set.

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

#28 Post by anikin »

Tested on Barry's Raring-5694, forgot to mention that.
However, I have the same result here on pemasu's Raring, usr/bin is empty :(

Code: Select all

make[1]: Leaving directory `/root/my-pets/tmp.OmPIHFgmAe/jwm-868/po'
install -d -m 0755 /root/my-pets/jwm-868-raring/etc/xdg/templates
install -m 644 example.jwmrc /root/my-pets/jwm-868-raring/etc/xdg/templates/system.jwmrc
install -d -m 0755 /root/my-pets/jwm-868-raring/usr/share/man/man1
install -m 644 jwm.1 /root/my-pets/jwm-868-raring/usr/share/man/man1/jwm.1
mv: cannot stat ‘/root/my-pets/jwm-868-raring/usr/local/bin/jwm’: No such file or directory
rmdir: failed to remove ‘/root/my-pets/jwm-868-raring/usr/local/bin’: No such file or directory
rmdir: failed to remove ‘/root/my-pets/jwm-868-raring/usr/local’: No such file or directory
Stripping
system.jwmrc
Splitting
man -> jwm_DOC-868-raring
Creating package(s):
PKG_FILE_NAME=jwm-868-raring
jwm-868-raring
        2236        2192  98% jwm-868-raring.pet
        2236        2192  98%
PKG_FILE_NAME=jwm_DEV-868-raring
PKG_FILE_NAME=jwm_DOC-868-raring
jwm_DOC-868-raring
        8516        8242  96% jwm_DOC-868-raring.pet
        8516        8242  96%
PKG_FILE_NAME=jwm_NLS-868-raring
If successful, the pets should be in /root/my-pets
#

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

#29 Post by Tman »

Anikin,

try replacing /usr/share/buildpet/desktop/jwm.bp with the following code and let me know what happens..

Code: Select all

#!/bin/sh

PKG_NAME="jwm"
PKG_VER="current"
PKG_REV="1"
PKG_DESC="window manager"
PKG_CAT="Desktop"
PKG_DEPS=""

download() {
	# download the sources
	if [ ! -f $PKG_NAME-$PKG_VER.tar.bz2 ]
	then
		wget --no-check-certificate http://joewing.net/projects/jwm/snapshots/$PKG_NAME-$PKG_VER.tar.bz2
		[ $? -ne 0 ] && return 1
	fi
	
	return 0
}

build() {
	# extract the sources
	tar -xjvf $PKG_NAME-$PKG_VER.tar.bz2
	[ $? -ne 0 ] && return 1
	
	#get the actual version number, from the folder that has been unpacked
	PKG_VER="`find -name "${PKG_NAME}-*" -type d | cut -f2 -d'-'`"
	export PKG_VER

	cd $PKG_NAME-$PKG_VER

	# configure the package
	./configure $BASE_CONFIGURE_ARGS --disable-debug
	[ $? -ne 0 ] && return 1

	# build the package
	make -j $BUILD_THREADS
	[ $? -ne 0 ] && return 1

	return 0
}

package() {	
	# install the package
	make DESTDIR=$INSTALL_DIR install
	[ $? -ne 0 ] && return 1
	
	#overwrite current jwm, if exists
	if [ "`which jwm`" != "" ];then
		JWMPATH="`which jwm`"
		JWMPATH="`dirname $JWMPATH`"
		echo "JWM PATH="$JWMPATH
		mkdir -p $INSTALL_DIR/$JWMPATH
		cp $INSTALL_DIR/usr/local/bin/jwm $INSTALL_DIR/$JWMPATH/jwm
		rm -rf $INSTALL_DIR/usr/local
	fi
	
	#create pinstall file
	echo "#!/bin/sh
echo 'jwm' > etc/windowmanager
exec usr/bin/jwm_menu_create &

TEXT=\"JWM Installer

JWM Homepage: http://joewing.net/

JWM's config files are in the ~/.jwm directory. 

JWM will start next time you restart the X server (see below)...

1. Go to 'Menu>Shutdown>Restart X' and JWM will load.

2. If that fails, go to 'Menu>Shutdown>Exit to Prompt', then type 'xwin jwm' and hit ENTER.
   
NOTE: To read this later, see ${HOME}/jwm-tips.txt 
\"
Xdialog --title \"JWM Installer\" --msgbox \"\$TEXT\" 0 0 
echo \"\$TEXT\" > ~/jwm-tips.txt" > $INSTALL_DIR/pinstall.sh
	chmod +x $INSTALL_DIR/pinstall.sh
	[ $? -ne 0 ] && return 1

	return 0
}
Thanks for testing and feedback.

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

#30 Post by anikin »

Still no joy, everything gets created except jwm itself.

Code: Select all

Creating package(s):
PKG_FILE_NAME=jwm-868-raring
jwm-868-raring
       10401       10074  96% jwm-868-raring.pet
       10401       10074  96%
PKG_FILE_NAME=jwm_DEV-868-raring
PKG_FILE_NAME=jwm_DOC-868-raring
PKG_FILE_NAME=jwm_NLS-868-raring
If successful, the pets should be in /root/my-pets
#
This is what I added to the new script

Code: Select all

./configure $BASE_CONFIGURE_ARGS \
	--prefix=/usr \
	--sysconfdir=/etc/xdg/templates \
	--localstatedir=/var \
	--disable-debug \
	--disable-icons \
	--disable-nls \
	--disable-fribidi \
	--disable-shape \
	--disable-xinerama \
	--disable-xmu
	[ $? -ne 0 ] && return 1
	
and also changed this to show 2: PKG_REV="2"

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

#31 Post by anikin »

Hi Tman,

Done it.
Must have been a fault in the source. It's version 869 now, and the script worked on it with flying colors. The only other thing I did differently this time, was the sequence of actions. Loaded devx first and then installed buildpet (pupmode 5 here, compiling in RAM). Great tool, it can/should reshape the way this community interacts. Instead of posting/downloading pets, one can have a script that will compile him a perfect app/proggram. Predefine "march=native" cflag, and the user will have the fastest, neatest code compiled exactly for his and only his processor. As for GUI, I'm against it for two reasons. We all will be better off if devs' time is spent on things that matter. Secondly, we noobs can learn a lot more if/when pushed to see what's going on under the hood.

Thank you.
Attachments
success.jpeg
(13.82 KiB) Downloaded 1417 times

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

#32 Post by Tman »

I find it very puzzling that the modified script still gave you errors, whereas it work okay for me. But at least it works for you now. When I gave you advice about, modifying /usr/bin/buildpet to keep the directory structures, I tried it myself will the Jwm build, and it would give me problems after the second time I tried to compile it.
So my advice now, is allow the directory structures to be deleted... in other words, keep it the way it was before.
If you really want to see the directory structure inside a pet, you can use the rox right-click option to "extract pet", or you can try my alternative: pet2dir_ROXrightclick-1.1.pet
anikin wrote:As for GUI, I'm against it for two reasons. We all will be better off if devs' time is spent on things that matter. Secondly, we noobs can learn a lot more if/when pushed to see what's going on under the hood.
My opinion is; first try the gui if you don't know what you are doing.
When you want to learn, then read the scripts and try to compile manually. After you understand how to compile and build pets, make your own scripts and use the terminal to debug.
After your script is finalized, use the gui to save time :).

Jasper

#33 Post by Jasper »

Hi Tman,

I was somewhat slow witted in understanding how to use your pet, but then I tried it to make a pet of the latest JWM version (869 test) and it was really smooth and easy and its size is only 74K (v 845 test - 96K).

Also, anikin's screen shot (two posts above) shows a jwm cog which suggests, to me, it is compiled machine code; whereas mine looks like a pet and installed as a pet?

My regards and thanks

I use Precise 5.6 with JWM and ROX from a Multi-session-Live-CD and have made an sfs from your pet as that will suit my personal needs best.

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

#34 Post by sc0ttman »

it just occured to me the problem with the jwm buildscript i made is almost certainly cos it uses which to find the 'old' jwm... it's dumb of me... jwm might not be installed.. that is off the top of my head..
[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]

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

#35 Post by anikin »

Hi sc0ttman,
... and I thought, why Akita was mentioned in that script :)

One more thing I forgot to mention. I have removed these:

Code: Select all

--disable-static --enable-shared --disable-debug --without-pic"
from my profile. Don't they belong to individual build scripts? They also show up in the compile log

Code: Select all

configure: WARNING: unrecognized options: --disable-static, --enable-shared, --without-pic

Post Reply