GooeyBuilder .9.2

[Induane]

Current Version in Repository: .9.2

Description:

GooeyBuilder is an easy to install and use tool for building PlaneShift from source.  Unlike other scripts, GooeyBuilder has a graphical interface allowing the user to simply point and click their way through the compiling process.  Currently GooeyBuilder is for Ubuntu Dapper ONLY!

Features:

• Finally FULLY Point and Click Interface
• Backup art directory in case this isn't the first build
• Can build bleeding edge or laanx compatible so you can play on the server
• Automatic dependacy resolution
• Sudo is now handled graphically so there is no need for an xterm in the background
• User sees no verbose output (only progress bars and friendly looking dialogs)
• Decent logging system.  Log file is generated in sections with obvious section names
• Gets CS and CEL from SVN repositories as CVS is now not used
• Allow users to select different install locations
• Uses a temporary sources.list file to make sure it fetches correct files

Caveats:

• Script does not provide optimizations for different architectures yet.  Selecting any processor will simply do a generic build.
• Script only supports Ubuntu Dapper Drake as of right now.
• A bug I'm trying to work out forced me to disable to automatic cvs retries for now. SVN continues to work normally.

ToDo:

• Add option to build with or without debug symbols
• Support more versions of linux with the script
• Finish support for processor optimizations and activate that feature
• Add better error handling
• Fix stupid errors
• Add ability to cross compile for windows (will never get around to this probabily)
• Add self destruct button for those that hate their computer
• Add capibility to use a source tarball instead

And now... SCREENSHOTS!



Left to Right: Backing up the art directory, password prompt, dependancy resolution, processor selection, downloading some sources.

Recent Changes:

• Fixed a minor path problem in my script
• Now has the ability to automatically get correct build dates, or build bleeding edge
• Beginnings of a setup/config utility for gooeybuilder
• Fixed some growing pains from the svn merge
• Uses a temporary sources.list file so your current setup is preserved

An online repository is available to help you stay up to date with GooeyBuilder

Instructions:

• Open a terminal - usually  Applications ------> Accessories----> Terminal
• Type:   sudo gedit /etc/apt/sources.list
• Go to the very bottom of the file this opens
• Enter this line including the slash at the end:

Code: [Select]

deb http://vaalnor.mine.nu/repositories/dapper/unstable /[li]Save the file and exit gedit[/li]
[li]Now back at the terminal type:  sudo apt-get update[/li]
[li]To install simply enter: sudo apt-get install gooeybuilder[/li]
[/list]

Note: This can also be done through synaptic.  Once you have edited the sources.list file and saved it and run sudo apt-get update, you should be able to install it through synaptic.  Also, once installed (whether via command line or synaptic) it will automatically update every time I release a new version, using Ubuntu's update manager feature.

If you are having any trouble with the repository simply download it here:http://vaalnor.mine.nu/repositories/dapper/unstable/gooeybuilder.9.2_all.deb

[ThomPhoenix]

This is nice! Thanks Induane! 

[Xordan]

Good work
I have a question on the processor optimization stuff... if this thing uses configure and jam (which I assume yes), then when you call the configure script for CS and PS, add --enable-cpu-specific-optimizations=max to the configure line and it'll automatically pick the best optimizations for the CPU.

[StarsAndBars_1018]

[li]Add self destruct button for those that hate their computer[/li]

[Wired_Crawler]

Good start!

I tried it on Mandriva and... well, it starts and tries to do what it is supposed to do, I'll make more tests later. apt-get and dpkg obviously don't work, but it is harmless - I have all dependecies installed.

For now two spotted bugs:
 - missing delay between cal3d source retrieval retries
 - window "Creating build environment" sometimes entirely covers "Enter your password" dialog, so You wait, and wait, and wait... (btw: should't it be "Enter root password ?")

I have also a suggestion about code - use some variables instead of hardcoded strings, like file paths, cvs repository paths... etc., it is easier and faster to change single variable than searching for strings in whole code, it would also allow to add user customizable parameters ("Where do You want to put sources ?").

[Induane]

I'll look into killing that window.  Zenity has a tendacy to stick around when it shouldn't sometimes.  Since Ubuntu Dapper uses sudo, and has no root eaccount enabled even, the password needed is the users password. Its convienent for me when writing the script as it is easier to run certain commands with root privlidges, and others without.  i.e.  sudo apt-get update    vs    su -----> then apt-get update  -----> then exit su root.  Later on there will be seperate sets of functions based on the distro you select.   Which probabily means its time to partition off my hard drive into about 5 more partitions, and install some more linuxes. Of course having them all listed in grub will be fun, especially mandravia which uses lilo I think instead.  The only other distro on my computer right now is Arch linux, so that will probabily be the next version of linux this script supports.

I have also a suggestion about code - use some variables instead of hardcoded strings, like file paths, cvs repository paths... etc., it is easier and faster to change single variable than searching for strings in whole code, it would also allow to add user customizable parameters ("Where do You want to put sources ?").

That will be added later as well.  I should have added that to the todo list... I probabily will here soon.  Eventually I'll add an option like - enter your own desired install location, or use defaults?  Then I'll have those represented as variables instead of strings.  The script will populate the strings with default values if they select default, and with whatever they enter as their desired directory.  I'm still expirementing with the file selection dialog so that is why its not an option yet.

I have a question on the processor optimization stuff... if this thing uses configure and jam (which I assume yes), then when you call the configure script for CS and PS, add --enable-cpu-specific-optimizations=max to the configure line and it'll automatically pick the best optimizations for the CPU.

From what I've read it makes semi intelligent decisions about processor optimizations.  The trouble is some optimizations aren't good for 3d game engines, etc.. I'm going to do alot of expirementing on different hardware to see what yields the best overall results.  I don't want to choose something that will degrade performance.  I'd rather optimizations be in my control.[/color]

[Induane]

Sorry to respond to my own post 

If anyone has any expirence with bash or more sugestions please let me know.  I'm sort of at writers block with only a few minor features to add that I think I know how to implement.  I'm also not that good with debugging, or bash in general.  If anyone has the time to look it all over, please do.  I could really use a few suggestions.

[Xordan]

I'll see if I've the time to look over it for you.

[Wired_Crawler]

Sorry to respond to my own post

Don't worry, look at Karyuu's statistics, she never checks Linux forums, Your firstborn is safe 
(On the other hand - Xordan may tell on You  )

Because it doesn't make sense to rewrite your script (it's Your project after all), here are my suggestions:

• If you really want to use bash as shell, the line

Code: [Select]

#!/bin/bash
must be the first line of the script

• I really recommend using variables from the beginning of the work, You will have less bugs later (for example: replacing strings in many places means more typing errors)
• don't put commands to variables, only command parameters, it makes code more readable and more flexible, like this:

Code: [Select]

GOOEY_VERSION=".6.1"

CS_CVS_REPOS=":pserver:anonymous:@crystalspace3d.org:/home/crystal/scm/crystal"
CAL3D_CVS_REPOS=":pserver:anonymous:@cvs.sourceforge.net:/cvsroot/cal3d"
CEL_CVS_REPOS=":pserver:anonymous:@crystalspace3d.org:/home/crystal/scm/cel"
PS_CVS_REPOS=":pserver:anonymous:@cvs.sourceforge.net:/cvsroot/planeshift"

BUILD_PATH="/opt/planeshift_cvs"

run_cvs() {
    cvs -z3 -d$1 $2 $3
    return "$?"
}

#.... somewhre $CVS_COMMAND and $CVS_ARGS is set
 
run_cvs ${CS_CVS_REPOS} ${CVS_COMMAND} ${CVS_ARGS}


• add a column with numbers (or other simple strings) as first column for zenity's radiolists, You won't need to use grep to recognize choices...
• (continuation of previous paragraph) ... and instead of using "if...then...fi" use "case $var in .... esac" statements, for example:

Code: [Select]

RET=`zenity --list --radiolist --column "" --column "#" --column "CPU" --column "Desc" \
     TRUE 1 "Pentium 4" "Optimize for P4" \
     FALSE 2 "Athlon 64" "Optimize for AMD64"`

case $RET in
      "1") CFLAGS="-mtune=pentium4"
           CXXFLAGS="-mtune=pentium4"
          # other instructions here
         ;;
      "2") CFLAGS="-mtune=athlon64"
          CXXFLAGS="-mtune=athlon64"
         PS_CONF_FLAGS="----enable-cpu-specific-optimizations=max"
        # other instructions here
        ;;
      *) #cancel was pressed ?
          return 1
          ;;
esac


• DON'T use "kill -9", it is last resort signal. Just use "kill" (defaults to kill -TERM). Besides - I think, that "Creating build environment." window is not needed, whole process takes miliseconds, so there is no need to display progress at all.
• implement MAX_RETRIES for source retrieval, example:

Code: [Select]

MAX_RETRIES=10
SLEEP_TIME=5

get_cs_source() {
    i=0
    until run_cvs ${CS_CVS_REPOS} co CS; do
          i=$(( $i + 1 ))
          [ "$i" -gt "${MAX_RETRIES}" ] && return 1;
          sleep $SLEEP_TIME;
    done
  return 0;
}
#...
get_cs_source 2>&1 | zenity --progress --pulsate --auto-close --text $"Getting Crystal Space sources, please wait..."

[ "$?" -eq "0" ] || { zenity --error --title "GooeyBuild Failed" --text "No Crystal Space - no Planeshift";
                             exit 1; }



• add error handling wherever possible and add appropriate messages (I hate messages like "Unknown error has occured")
• avoid putting zenity in background (maybe use "|" as in above example)
• always set one of choices in radiolists to TRUE

Enough for now ...?

[Induane]

If you really want to use bash as shell, the line
Code:
#!/bin/bash
must be the first line of the script

OMG How could I have forgotten that!?!?!!!

don't put commands to variables, only command parameters, it makes code more readable and more flexible, like this:

Understood.  I'll make those changes asap.

add a column with numbers (or other simple strings) as first column for zenity's radiolists, You won't need to use grep to recognize choices...

Good idea.  That eliminates the need to have a special unique word in each option.

... and instead of using "if...then...fi" use "case $var in .... esac" statements, for example:
Code:

I'll give that a shot.  I've never used the case syntax before so I'll mess with some test scripts to see how it works and get a feel for it, and if its cool I'll make those changes lol ....sniff....but grep is so dang cool!

DON'T use "kill -9", it is last resort signal. Just use "kill" (defaults to kill -TERM). Besides - I think, that "Creating build environment." window is not needed, whole process takes miliseconds, so there is no need to display progress at all.

OK I'll throw out the -9 its just a bad habit of mine.  I'll eliminate that window too, as I also noticed that it appears only momentarily, and basically because of a sleep hack.

implement MAX_RETRIES for source retrieval

That was listed in my caveats but not in my todo list for some odd reason.  Hehe.  Not sure why not, but I was basically pondering the inplementation.  I'd been working on a way to do it.  I had been thinking about a for loop, that repeated a command until the count ran down.  You way looks cool and complex, I'll mess with trying to understand it

add error handling wherever possible and add appropriate messages (I hate messages like "Unknown error has occured")

Yea... it was on my mental todo list.

avoid putting zenity in background (maybe use "|" as in above example)

Not sure what you mean there. Heh... My skull is a bit thick.

always set one of choices in radiolists to TRUE

I don't understand this one either.

Enough for now ...?

BRING IT ON![/color]

[Wired_Crawler]

avoid putting zenity in background (maybe use "|" as in above example)

Not sure what you mean there. Heh... My skull is a bit thick.

Instead of worrying about killing zenity windows, let the shell take care of it. Operator "|" creates pipeline, through which data flow from one command to the next (from left to right). This gives the following advantages:

• zenity window closes automatically, when command before "|" sends EOF marker (=it is completed or failed) and "--auto-close" was specified; without auto-close OK button becomes active and user has to press it.
• pressing "Cancel" in zenity window causes "Broken pipe" error and whole script ends returning error code. Example:

Code: [Select]

get_cs_source | zenity --progress --pulsate --auto-close --text "Getting CS sources, please wait..."
The window will close after CS sources are succesfully retrieved (or not), and when user presses "Cancel" installation will be canceled.

• for progress dialogs You really can display progress by sending appropriate data (it is described in gnome-help -> Desktop -> Zenity). So, You can even display progress of compilation! Simple example:

Code: [Select]

{ echo -e "#at target 500... \n50"; sleep 5; echo -e "#at target 900... \n90"; sleep 5; echo -e "#almost done...\n99"; sleep 2;  } | \
zenity --progress --auto-close --width 400 --text "Compiling Crystal Space"
[/list]

always set one of choices in radiolists to TRUE

I don't understand this one either.

Look at my second example from previous post. The first element (Pentium4) has TRUE in first column, so it will be selected by default. By default You can set "No optimization" for users, which don't know, what cpu they have ;) and they will just press OK to accept default choice.

Enough for now ...?

BRING IT ON!

Two more hints:

• instead of "ps -U root -u root u | grep synaptic | grep -v grep" it is sipler to use command pgrep; if synaptic is running "pgrep synaptic" will return pid of process and exit code will be 0, otherwise exit code will be 1.

Code: [Select]

if pgrep synaptic &>/dev/null; then
   zenity --error --text "Please close synaptic"; exit 1;
fi


• implement UPDATING sources instead of deleting them and downloading again

Hmmm... Now it is Your turn  :P. You have opportunity to learn something new AND You can discover some things, which I don't know... Waiting for version .6.2 or later...

[Induane]

# zenity window closes automatically, when command before "|" sends EOF marker (=it is completed or failed) and "--auto-close" was specified; without auto-close OK button becomes active and user has to press it.
# pressing "Cancel" in zenity window causes "Broken pipe" error and whole script ends returning error code. Example:
Code:
get_cs_source | zenity --progress --pulsate --auto-close --text "Getting CS sources, please wait..."
The window will close after CS sources are succesfully retrieved (or not), and when user presses "Cancel" installation will be canceled.

Seriously awsome suggestion!  That cleans up the code SO much and makes it work better too.  So simple yet I never thought of it thanks!

5 seconds later....

cvs [login aborted]: received broken pipe signal
cvs [login aborted]: received broken pipe signal
cvs [login aborted]: received broken pipe signal
cvs [login aborted]: received broken pipe signal
cvs [login aborted]: received broken pipe signal
cvs [login aborted]: received broken pipe signal
cvs [login aborted]: received broken pipe signal
cvs [login aborted]: received broken pipe signal

goes on indefinately with this method... is a kill also necessary?[/color]

[Wired_Crawler]

I guess You kill zenity before "cvs login" ends... or You gave wrong parameters to zenity and it does not start at all. So the answer is: no, kill is not necessary. I would need to see current version to give full answer. It works for me...

[Induane]

Here is what I think is going on.  If you stop the first part of a pipe, then it kills zenity automagically.  The bad part is if you kill zenity, it doesn't kill the first command before the pipe.  There must be a way to detect and handle the cancel button zenity uses, but I can't find it in the documentation.

[Wired_Crawler]

The command on the left side will die because of broken pipe. Unfortunately, cvs always returns exit code 1, regardless of the reason, so you can't distinguish between network error and canceling zenity. You must use dirty trick here: add inside a loop, which retries downloading sources, any shell command, which tries to write to stdout, for example "echo '#Retrying...'". This will cause death not only to cvs, but also to subshell, in which download loop runs.
You can also add at the very beginning of buildscript "trap 1", which will prevent the main shell from exiting after reseiving SIGHUP (after pipe is broken), and the buildscript will continue. Read about debug traps in bash manual.

edit: ...or use trap to display nice info window before exiting, for example:

Code: [Select]

trap 'zenity --error --text "Canceled !!!"; exit 1' 1