Kernel word recovery crack, Mobile themes website for samsung wave 525, Dekha ek khwab sony tv title song, Song zombies on your lawn, Bloody mary nerve endings mp3, Digittrade tv jukebox, Padosan songs mp3, Gold cup series 70 manual, Nieuwste versie van mozilla firefox en, Cant install spotify on mac, Web brute force password cracker, Belkin g peek driver windows 7

Debian packages, auto{make,conf}

July 19th, 2008 by Martijn Leave a reply »

I’ve been playing a little with automake and autoconf again. Nothing new, I still hate them, maybe more, even if I understand the vital role they play in the open source community.

I was about to write a rant-like post about the difficulties I encountered, but instead I’ll just post what I learnt.

– Put the source files in a src/ subdirectory of the project.
– Run autoscan, copy configure.scan to, and edit it.
– Create a in the project directories containing the line: SUBDIRS = src
– Recycle a to put in the src/ directory from another project or an online example because the syntax is impossible to remember.
– touch README, AUTHORS, NEWS, ChangeLog
– Get the [ script][autogen] copy it to the project directory and run it. This will avoid running autoreconf -i, which seems to be a good thing according to some. *shrug*
– Do the ./configure && make dance
– Save your work with sudo make distcheck

This all seems quite a lot of work and line noise for a project consisting of a single C file. Of course environments like [KDevelop][kdevelop] make this a lot easier (and allow you to choose [other build ][cmake] environments still unknown to me).

For my playing with qt-4 I use [qmake][] (what else ? ;) ) The build process for that is rather easier:

– qmake-qt4 -project
– qmake-qt4
– make

I don’t know about building libraries and plugins with qmake yet though, but the documentation is a treat compared to the archaic GNU info pages.

Now, I’ve been wanting to make .deb packages too. And again lost a lot of time to learn boring stuff. Instead of complaining I’ll try to share some of the things I learnt. Without the help of an article on [][deb-adm] it would have been much harder.

– make sure the project is in a directory named in the form project-0.1.2
– run dh_make -n -e youremail@yourhost -s -c gpl (for a GPL’d project)
– rm debian/*.{ex,EX} debian/README{,.Debian}
– edit debian/control and debian/copyright
– run fakeroot debian/rules clean if you haven’t run make dist-clean before.
– run debian/rules build
– run debuild -uc -us -b to create a binary .deb in the parent directory
– run debuild -uc -us -S to create a source .tar.gz in the parent directory

To update a project’s version after some changes, the following steps seem to be necessary:

– rename the project folder to reflect the new version
– update the version in
– rerun
– run debchange and add to the changelog.

Now integrating all this with my favourite version control system, [Bazaar][bzr], will probably be a lot of fun…

[autogen]: “ aka buildconf”
[kdevelop]: “KDevelop”
[cmake]: “CMake”
[qmake]: “QMake manual”
[bzr]: “Bazaar version control system”


Leave a Reply

Authorized tags:
[b]bold[/b] [u]underline[/u] [i]italic[/i] [url=http://link.url]link[/url] more