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.
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:
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.
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!
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.
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 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.
]]>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.
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.
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:
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 :))
]]>