Last week I went to the 2005 Python “Conference”:http://python.org/pycon/2005 in Washington, D.C. and I’m *still* trying to process all of the information from the conference itself let alone the four days before (aka – the sprints.) There are a lot of very bright and intelligent people who attend PyCon and the whole thing has a very friendly feel to it – so very non-corporate.

The biggest feeling that I get from this year is that Python is ready to take center stage as a RAD tool – sure people will always throw the “but it’s interpreted” argument out, but that is really just a minor issue. The way people are creating serious apps and how quickly they turn them around and without a lot of v1.0 bugs is pointing to the maturity of the language.

I will be going thru the various sessions I went to and be creating log entries for each one high-lighting what I thought was key points from them.

Hopefully both of you will find it interesting.

As I find out new (to me) items about building RPM’s, I’ll post them here — not that the info isn’t out there already, it is just kinda hard to find.

The first item is something that anyone who gets past the “oh I built an RPM” stage ponders: How do you pass in the version and release information so you don’t have to keep editing the .spec file.

On the @rpmbuild@ command line, you can define macros. This allows you to reference the macro values in the .spec file. For example:

bq. @rpmbuild -ba –define “name value” –define “name2 value2″ foo.spec@

and in foo.spec you can have:

bq. Version: %{name}
Release: %{name2}

That is all there is to it — now for extra credit locate any mention in the man page or any online web page of –define :)

A handy file to scan thru to see the possibilities for macros is /usr/lib/rpm/macros (well at least that’s where it is on my “ubuntu”:http://www.ubuntulinux.org server.)

Well, I’ve gone down the “could it be makefile rule errors” rabbit hole and have come out the other side — but the issue is still there. The info that I’ve gathered is pointing to a more “normal” issue where the files from one build are not cleared out before starting another. But I’m not sure about that either, my time has been taken up with doing wxPython builds for the dev team and testing builds on my powerbook is a lesson in patience.

I’ve been tracking down a build issue that just started happening today on the OSX build server and the error seems to be not related to any source that was checked in today, but rather with something in the environment that may have been lurking for a couple days now just waiting for the right time to pounce!

The sympton is that during a “release” build (DEBUG=0) the python build would fail during the ./configure step with this error:

bq. checking for getaddrinfo… yes
checking getaddrinfo bug… buggy
Fatal: You must get working getaddrinfo() function.

Now most normal people would figure that something was up with python or ipv6 or the normal culprits but when you look at the config.log output for the debug build, this check is *exactly* the same. One of the OSAF devs (thanks Grant B.) even generated a test binary for me to run and it returned with no errors.

Great.

To make matters worse, the scripts that run the tinderbox immediately clean the environment if a build fails so I had to resort to local hacks to get the log outputs.

After running down a couple dead-ends, more than I care to admit right now, I was finally able to get a command sequence that would reproduce it from the command line so I wasn’t tied to running hacked scripts. Basically if I ran “make DEBUG=0 realclean all” it would fail, but if I ran “make DEBUG=0 realclean world” it worked.

Hmmmmmm

Looking at the Makefile revealed a couple key difference between the two options and checking the tinderbox scripts revealed that they used the “all” method whereas the wiki page touted the “world” option. Here is the segment of the Makefile showing both targets:

bq. .PHONY: sources expand binaries $(SYSTEMS)
env::
mkdir -p $(PREFIX)/bin $(PREFIX)/lib $(PREFIX)/include
sources: env
for system in $(SYSTEMS); \
do \
$(MAKE) -C $$system sources; \
done
$(SYSTEMS):
$(MAKE) -C $@ DEBUG=$(DEBUG)
all: env sources $(SYSTEMS)
world: all binaries install
make -C ../internal DEBUG=$(DEBUG) world

After going back and refreshing my understanding of the “::” “Double Colon Rules”:http://www.gnu.org/software/make/manual/html_chapter/make_4.html#SEC50 I saw that according to the manual you cannot have the double-colon item, “env” in our case, that all rules that have “env” must also be double-colon rules.

Well, that’s how I’m reading it – let me know if that’s wrong.

Going with that thought I made a simple change to the Makefile and re-ran the tests:

bq. all: source $(SYSTEMS)

and my testing worked and as I type this the full OSX tinderbuild is in progress and hopefully it will work there or it’s back looking for another issue :(

I’ll update the journal later with the results – I’m off to bed.

After reading the last two entries, I realize I will probably have to dip into pyBlosxom and setup categories and some other of the more useful web log items. I’m thinking tracebacks (you just gotta get that ego hit ;) and maybe even comments. I’ll have to do some trapsing thru Ted’s “web log”:http://www.sauria.com/weblog to see which modules he uses – always better to learn from others instead of rolling your own.

I wonder where I put that personal todo list ;)