Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Tue 21 Oct 2014, 19:59
All times are UTC - 4
 Forum index » Advanced Topics » Additional Software (PETs, n' stuff) » Compiling
Buildpet
Post_new_topic   Reply_to_topic View_previous_topic :: View_next_topic
Page 2 of 3 Posts_count   Goto page: Previous 1, 2, 3 Next
Author Message
amigo

Joined: 02 Apr 2007
Posts: 2257

PostPosted: Thu 19 Sep 2013, 10:04    Post_subject:  

@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.
Back to top
View user's profile Send_private_message 
sc0ttman


Joined: 16 Sep 2009
Posts: 2385
Location: UK

PostPosted: Thu 19 Sep 2013, 14:36    Post_subject: Re: Buildpet is it now v0.4 or v0.5?  

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..
buildpetui.tar.gz
Description  unzip, run the script..
gz

 Download 
Filename  buildpetui.tar.gz 
Filesize  1.44 KB 
Downloaded  230 Time(s) 

_________________
Akita Linux, VLC-GTK, Pup Search, Pup File Search
Back to top
View user's profile Send_private_message 
gcmartin

Joined: 14 Oct 2005
Posts: 4355
Location: Earth

PostPosted: Thu 19 Sep 2013, 17:02    Post_subject:  

BuildPetUI
Should I have the DEVX loaded when executing the script? or is a parm/filename required?
Code:
# 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
_________________
Get ACTIVE Create Circles; Do those good things which benefit people's needs!
We are all related ... Its time to show that we know this!
3 Different Puppy Search Engine or use DogPile
Back to top
View user's profile Send_private_message 
sc0ttman


Joined: 16 Sep 2009
Posts: 2385
Location: UK

PostPosted: Thu 19 Sep 2013, 18:52    Post_subject:  

gcmartin wrote:
BuildPetUI
Should I have the DEVX loaded when executing the script? or is a parm/filename required?
Code:
# 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..

_________________
Akita Linux, VLC-GTK, Pup Search, Pup File Search
Back to top
View user's profile Send_private_message 
Tman


Joined: 22 Jan 2011
Posts: 814
Location: Toronto

PostPosted: Fri 20 Sep 2013, 02:35    Post_subject:  

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
Back to top
View user's profile Send_private_message 
simargl8

Joined: 06 Feb 2013
Posts: 65

PostPosted: Fri 20 Sep 2013, 04:42    Post_subject:  

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:
[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
Back to top
View user's profile Send_private_message Visit_website 
simargl8

Joined: 06 Feb 2013
Posts: 65

PostPosted: Fri 20 Sep 2013, 13:42    Post_subject:  

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.
Back to top
View user's profile Send_private_message Visit_website 
simargl8

Joined: 06 Feb 2013
Posts: 65

PostPosted: Sun 22 Sep 2013, 12:56    Post_subject:  

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/
Back to top
View user's profile Send_private_message Visit_website 
Tman


Joined: 22 Jan 2011
Posts: 814
Location: Toronto

PostPosted: Sun 22 Sep 2013, 15:02    Post_subject:  

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.
Back to top
View user's profile Send_private_message 
simargl8

Joined: 06 Feb 2013
Posts: 65

PostPosted: Sun 22 Sep 2013, 17:29    Post_subject:  

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.
Back to top
View user's profile Send_private_message Visit_website 
anikin

Joined: 10 May 2012
Posts: 506

PostPosted: Tue 24 Sep 2013, 13:18    Post_subject:  

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.

.
Back to top
View user's profile Send_private_message 
Tman


Joined: 22 Jan 2011
Posts: 814
Location: Toronto

PostPosted: Wed 25 Sep 2013, 02:15    Post_subject:  

simargl,
Duly noted Razz (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:
rm -rf $PKG_FILE_NAME

add a # symbol to the start of that line, and you're set.
Back to top
View user's profile Send_private_message 
anikin

Joined: 10 May 2012
Posts: 506

PostPosted: Wed 25 Sep 2013, 07:19    Post_subject:  

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 Sad
Code:
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
#
Back to top
View user's profile Send_private_message 
Tman


Joined: 22 Jan 2011
Posts: 814
Location: Toronto

PostPosted: Wed 25 Sep 2013, 12:02    Post_subject:  

Anikin,

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

#!/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.
Back to top
View user's profile Send_private_message 
anikin

Joined: 10 May 2012
Posts: 506

PostPosted: Wed 25 Sep 2013, 13:50    Post_subject:  

Still no joy, everything gets created except jwm itself.
Code:
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:
./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"
Back to top
View user's profile Send_private_message 
Display_posts:   Sort by:   
Page 2 of 3 Posts_count   Goto page: Previous 1, 2, 3 Next
Post_new_topic   Reply_to_topic View_previous_topic :: View_next_topic
 Forum index » Advanced Topics » Additional Software (PETs, n' stuff) » Compiling
Jump to:  

Rules_post_cannot
Rules_reply_cannot
Rules_edit_cannot
Rules_delete_cannot
Rules_vote_cannot
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1358s ][ Queries: 12 (0.0158s) ][ GZIP on ]