« Posts tagged build

How to speed up RPM building

September 28, 2010 / posted in Planet CDOT / 1 Comment

If you’ve run into a situation where you wanted to repeatedly test some code in your .spec file after the %build process, you know you have to wait for the application to re-compile every time. For larger RPMs this waiting compounds to a lot of lost time.

During my build for CodeLite I ran into several issues, mostly when cleaning up the rpmlint messages from the resulting package. The average build time was around 16 minutes with the optimal make -j value. It doesn’t sound like much but if you have to compile 5 or 6 or 7 times, it adds up.

The .spec macros will do cleaning of the working directories every time you execute rpmbuild -ba and for good reason. Ideally you should re-compile every time to ensure a repeatable build environment, however if you are impatient like me try the following:

I assume you…

  • have already tested and confirmed your package compiles successfully with rpmbuild -ba
  • are confident the build process can be skipped safely without compromising the rest of the .spec file
  • understand that this is for testing purposes only and the .patch created below will not be included in the final .rpm
  • understand this particular .patch file should only be used on the system it is created

First of all, expand the source tarball to two separate directories: pkg and pkg.compiled.

Navigate to the pkg.compiled directory and go through the configure and make process mirroring the %build process from your working .spec file. You do not need to ‘make install’ and this point.

Change the directory to the pkg.compiled parent and run the following:

$ diff -Naur pkg pkg.compiled > ~/rpmbuild/SOURCES/app-version-skip_make.patch

You will be using this patch file to “trick” the %build process into skipping most of the compiling process. I say most because make may detect inconsistencies in the source directory after the patch and go through some re-linking.

The next step is to add this patch to your .spec file:

...
Patch99:    app-version-skip_make.patch
%prep
%setup -q
%patch99 -p1
...
%build
#%configure
make
...

Notice I’ve commented out %configure because the patch file will take care of this also.

You can now go through the rpmbuild -ba process again and you should see a very significant speed increase.

Using this, I was able to decrease the build time for CodeLite by 400%!

Good luck, and remember to remove this patch from your final RPM.

Building CodeLite and finding its dependencies

September 15, 2010 / posted in Planet CDOT / 1 Comment

I found CodeLite (2.6.0.4189 as of today) on sourceforge.net and it seems like a useful tool for programming under Linux. It’s got the goodness of syntax highlighting for a bunch of languages:

C/C++
Java
Perl
XML
Makefile
Lua
Diff files
PHP
JavaScript
Python
HTML
ASP

It’s cross-platform and fairly easy to compile and install. It can debug (built-in gdb support), compile and the highlighting for Makefile/Perl/C/Python/Diff should prove quite useful for SBR. See their website for more info on the features.

I’ve done the following under Fedora 13 x86, but the process should be similar for all the other popular platforms:

$ wget [some sourceforge mirror]/codelite-2.6.0.4189.tar.gz
$ tar xvf codelite-2.6.0.4189.tar.gz
$ cd codelite-*
$ ./configure
$ make
# make install
$ codelite

That’s it. Now obviously there are dependencies and a C++ compiler is needed to do the build (g++ to be exact). Fedora13 and the wonderful yum makes this process easy.

Download and install the following packages:

wxGTK-devel (you will neex wx-config to build the Makefile)
gcc-c++ (the g++ binary needed to ‘make’)

I looked for a *g++* package on the repositories but couldn’t find anything. I thought it was odd since a GNU C++ compiler should be a fairly common so I did this:

# yum install "*/*g++"

This was great and all but it listed something like 47 packages. I obviously did not need that many and looking through the list, gcc-c++ stood out.

I figured that when looking to install dependencies it’s a good idea to keep the as lean as possible. This way I can figure out exactly what package fixed what issue as well as avoid or at the very least minimize conflict with other applications.

The wxGTK-devel is the package name on FC13′s repositories so it should be easy to install. Before running ./configure make sure wx-config is in $PATH.

It also looks like CodeLite is trying to sync with a VCS using svn at start-up but it is not a requirement.

This is the final product: