Why have code guideline and hang on it?

I’ve been coding since I was kid. I didn’t know better way to waste my time that sitting front of Commodore 64 and hack together some BASIC code and my code was horrible.
I didn’t have any clue how to organize it or how to make it more readable (BASIC ain’t that BASIC when you try to read it afterwards). Years after some major Assembly experiences on 286 and 386 I found Pascal. Then I understood one thing. If you don’t understand your stuff you write you don’t understand it after a while! So I tried to be more constructed what I did (Pascal/Delphi still have soft spot in my heart.. always!) and forget it sort after that for almost 10 years.

Doing it professionally

If you code for living you have to be very sure you can read your code and others can also. You can stop developing your code after that someone else can come to maintaining that particular code and this is situation in open source most of the time.
You never know how long you code will be used, forked or maintained by someone else brave after you have moved on to something more interesting.
Following code guidelines is not very difficult. You just forget about your excuses about beauty of your code and ignorance about making code look solid with rest of application. Most horrible
is read some code that where you have to learn how different people write code and their definition about good code guidelines.
If you lazy like me you can use tools like:

• http://astyle.sourceforge.net/
• http://jsbeautifier.org/
• http://pear.php.net/package/PHP_Beautifier/

I do want my code to look like I did it

No you don’t if you contribute to someone else project you make you code look like his or her code. Structured code is always looking good.
We have policy that version control system make decision how code should look like. So there is some tool and version control hook script that structures code to what is our stated our code guidelines and believe me it have worked better than I expect. People still have to make changes but you have reply what is wrong. No more rants about what is correct looking code and people giving me excuses why code is not following code guidelines. There is only one that have dictatorship here and it’s version control system and 99.9% it does good job.

Code guidelines are not equal Code quality

No they are not. They have nothing to do with Code quality control or do they? openSUSE Build service have very good for everyone to take good example. To make your RPM package SPEC-file compile to binary or source RPM you have to follow machine checked rules. If you correct at least those it will be all okay. Scripts check that you don’t have million bytes long jargon in Summary-line or you have Summary-line at all. They run rpmlint and check C-code for some we’ll known problems. If they are qualified enough to go through this you won’t get your RPM/DEB/Arch-package.
Now we can argue long time do static code checking have any value but long time user of static code checking tools like cppcheck I can tell static analyzing find many that people just ignore to find because they don’t have time to thing whole logic or understand that memory handling issue.
Best way to use them I again run them on version control system hook before code gets in. It won’t make code perfect but you make developer fear for commiting and when developer fear they make better code.
After you have structured code and machine checks it statically it’s much easier to get in to point and find problems. So you can talk about what is really wrong or right with code. It’s easier to read some text if that have passed thesaurus in Libreoffice and again openSUSE obs policy is very very efficient. It spots stuff that you don’t care about and yes I miss SPEC code structure-script in OBS but you can’t have all.
Now it’s time make code guidelines to you project and use some tool to make all project look like it (My opinion is that have always some for example Artistic Style tool example how to structure code for your with code guidelines) and that FFmpeg stuff is coming when I feel it’s ready to rock!

Fedora distribution or RHEL

RPM based Linux distributions are very easy with OBS. You just have to make SPEC file generic. If you like to do it right you should read openSUSE:Build Service cross distribution howto and learn how to do it.

OBS and DEB based distributions

This is little bit trickier but not much. You needed decent DSC-file (Most dsc files goes without changes. If you like to use Bzip2 file then you need to add ‘DEBTRANSFORM-TAR’ in dsc-file) file and then you need ‘debian.tar.gz’ in your project or ‘debian/’-dir in your project. What are files that you need in you debian package/dir? That is a very good question and it stays unanswered here because it’s not point of this blog. If you are curious enough you can always download ‘debian.tar.gz’ from example application and study files or look Debian documentation about it.

Arch

Arch is most unknown distribution for me but it has vibrant community and active development so providing packages to them is good thing. They seems to like live bleeding edge. So Just add Arch distribution in your project in OBS and then fill PKGBUILD-file with necessary lines and like magic you have Arch supported (Look at example PKGBUILD-file if you don’t understand a thing).

This was it! No more articles about GCC or around it. Next I’ve going to dive low level Linux Multimedia especially in audio and FFmpeg (and how you do them in openSUSE). if you haven’t read rest of articles and you feel you missed something. Go on a read them and if you missed good OSC-blog you can read it too.

RPM agnostics

There is actually two kinds of RPMs. Binary RPM and then there is Source RPM. Source RPM contains everything needed to compile this package again. Source rpm ending is ‘.src.rpm’ or ‘nosrc.rpm’. Binary RPM is architecture specific. So if you have ‘arm7v.rpm’ it wont run your x86_64 or x86 machine because it’s ARM7 binary code. There is also noarch.rpm that is architectural non specific.
In openSUSE traditionally if you build RPM it goes to ‘/usr/src/packages’ directory and there is sub directories

BUILD/ - Building is done here
SOURCES/ - Contains needed sources for building including patches
SRPMS/ - Where Source RPMS are placed after build
BUILDROOT/ - This is ROOT place where make install places installed files (because you don't want them to go real root dir) 
RPMS/ - All the RPMs are placed here (It contains i686, x86_64 and noarch subdirs where those arch files are placed)
SPECS/ - Where .spec files are placed

So if you build i686 RPM with your x86 openSUSE then it would go to ‘/usr/src/packages/RPMS/i686’ directory and Source RPM ‘/usr/src/packages/SRPMS’ directory.

Example

Now you should read Part 7 and part 6 of this series to have example application and autotools installed. then we install rpm-build

zypper install rpm-build

and make distribution tar-ball of sdl_displaybitmap with

make dist

there should be ‘sdl_displaybitmap-1.0.tar.bz2’ file now in same directory. then copy this SPEC file to file named ‘sdl_displaybitmap.spec’ in same directory you have ‘sdl_displaybitmap-1.0.tar.bz2’

Name:           sdl_displaybitmap
Version:        1.0
Release:        1%{?dist}
Summary:        Some SDL Sample

Group:          Amusements/Toys/Other
License:        SUSE-Public-Domain
URL:            http://content.gpwiki.org/index.php/SDL:Tutorials:Displaying_a_Bitmap
Source0:        sdl_displaybitmap-1.0.tar.bz2
BuildRoot:      %{_tmppath}/%{name}-%{version}-build

BuildRequires:  gcc
BuildRequires:  SDL_image-devel
BuildRequires:  libtool
BuildRequires:  automake
BuildRequires:  autoconf

%description
Small example how to use SDL to display bitmap

%prep
%setup -q

%build
%configure
make %{?_smp_mflags}

%install
rm -rf $RPM_BUILD_ROOT
# There is nothing to install so we do it with hand
#make install DESTDIR=$RPM_BUILD_ROOT

mkdir -p $RPM_BUILD_ROOT%{_bindir}
mkdir -p $RPM_BUILD_ROOT%{_datadir}/%{name}
cp SDL_DisplayBitmap  $RPM_BUILD_ROOT%{_bindir}
chmod +x $RPM_BUILD_ROOT%{_bindir}/*
cp image.bmp $RPM_BUILD_ROOT%{_datadir}/%{name}

%clean
rm -rf $RPM_BUILD_ROOT

%files
%defattr(-,root,root,-)
%doc LICENSE.TXT
%{_bindir}
%dir %{_datadir}/%{name}
%{_datadir}/%{name}/*


%changelog

and copy our tar-ball to ‘/usr/src/packages/SOURCES’. After that we build rpmbuild command to create RPM packages

rpmbuild -ba sdl_displaybitmap.spec

If everything goes right you should have this RPM in ‘/usr/src/packages/RPMS/YOURARCHHERE/sdl_displaybitmap-1.0-1.YOURARCHHERE.rpm’ and SRPM in ‘/usr/src/packages/SRPMS/sdl_displaybitmap-1.0-1.src.rpm’. You can check with less that what files it contains

less /usr/src/packages/RPMS/YOURARCHHERE/sdl_displaybitmap-1.0-1.YOURARCHHERE.rpm

OBS If you install this RPM it won’t work! Application only works if you go to folder ‘/usr/share/sdl_displaybitmap’ and run it there. Next time we patch our app to work from other places also.

What does this mean?

There is better documentation else where than I can write. For openSUSE conventions see Packaging in Wiki. If you curious read it from there and learn. Next time we make OBS (openSUSE Build Service) build from this RPM and last part is how we use OBS to create also Debian, Ubuntu and Fedora packages from our marvelous app.

wxRuby is an old but working library based on wxWidgets toolkit, till some day ago the dependency from SWIG 1.3.38 and some small errors raised during the manual compilation, made the use of this library the worst nightmare for beginners who was looking for a fast approach to GUI based programming in Ruby.

After some day spent to investigate about a possible upgrade of the SWIG dependency to the current 2.0 version, i produced some patches to fix this and the other annoying compiling errors, and finally, thanks to the Buildservice infrastructure, a wxRuby RPM compiled from sources with the relative patches are now availables for all openSUSE users!

As far i googled this should be the first distro to have a precompiled and working wxruby gem among its repositories (being compiled from sources the gem is generated for 32 and 64 bits architecture from Buildservice itself), so Rubyists take a look on software.opensuse.org, select the package coming from my home project account and enjoy!

Usually need install the wxGTK libraries and the gem wxruby (or wxruby-ruby19 if using ruby 1.9) and start creating your own scripts.

$ sudo zypper in wxGTK wxGTK-gl
$ sudo gem install wxruby

But sometimes we could find an Error for a wrong compatibilty between the installed version of the wxGTK libraries and the wrapper library included in the gem.

/usr/lib/ruby/gems/1.8/gems/wxruby-2.0.1-x86-linux/lib/wxruby2.so:
symbol _ZN13wxAuiNotebook14ShowWindowMenuEv, version WXU_2.8.5 not defined in file libwx_gtk2u_aui-2.8.so.0 with link time reference -
/usr/lib/ruby/gems/1.8/gems/wxruby-2.0.1-x86-linux/lib/wxruby2.so

When an error like this appear, the unique solution is recompile the gem.

What we need:

• rubygems: Tool for manage the ruby’s gems;
• rake: the Ruby’s version of the popular make, will help us to compile wxRuby;
• wxGTK, wxGTK-gl, wxGTK-devel: Library and headers needed for run our scripts and produce the object’s file;
• SWIG: Build the wrapper classes in Ruby from the C++ sources, wxRuby 2.0.1 need the version 1.3.8;
• gcc-c++: The C++ compiler used for build the wrapper library;
• wxRuby: We have to download the source’s package directly from Rubyforge.

Added the repository which contains the Ruby extensions (warning to the portion of the address that refers the version of openSUSE), we can proceed with the installation confirming the request of the dependent packages:

$ sudo zypper ar http://download.opensuse.org/repositories/devel:/languages:/ruby:/extensions/openSUSE_11.3/ RubyExtensions
$ sudo zypper ref
$ sudo zypper install rubygems rubygem-rake gcc-c++ wxGTK-devel rubygem-ffi-swig-generator make

It’s time to download the sources of SWIG version 1.3.38 from sourceforge, then uncompress and install it:

tar -xvf swig-1.3.38.tar.gz
cd swig-1.3.38
./configure && make
sudo make install

All the packages are ready, we have to set some environment variables before continue:

export SWIG_CMD=/usr/local/bin/swig
export WXRUBY_EXCLUDED=GLCanvas
export WXRUBY_VERSION=2.0.1

The second instruction is important for ignore all the references to the openGL library, which are not availables in unicode version.

The next step is download the wxRuby’s source from Rubyforge and start to compile

tar -xvf wxruby-2.0.1.tar.gz
cd wxruby-2.0.1
rake

After this procedure end you can remove the old gem and build & install the new:

rake gem
sudo gem install wxruby-2.0.1-x86-linux.gem

Personally, I needed recompile wxRuby in openSUSE 11.2; with the new version (11.3) standard packages work fine, anyway i wished share my experience for someone could meet the same trouble in the future :))