(no subject)

apm did a nice write-up of ExtremeProgramming. About courage in XP: it's also about making changes that would seem dangerous in a more conservative development methodology, relying on the extensive test scaffolding that XP requires.

Note that there already is a OpenSourceExtremeProgramming page on Wiki, for those interested. Link in that page, like ExtremeHacking, are also of interest.

I am trying to develop XPLC in such a OSS/XP mix. For example, unit tests comes with every parts of the system and it is very easy for a developer to simply run a "make test" before doing a CVS commit. Of course, since I'm alone on that project, it's rather hard to follow-up on the "pair programming" part!

I wouldn't totally agree with his claim that "most OSS projects are pretty good at adhering to coding standards". The largest ones sure do (they would collapse otherwise), but I would say that you see a lot of variation in this department.

I hacked autoconf into Quadra today. I'm a bit afraid that we'll have to bite the bullet and modularize the thing (as in dynamically loaded shared objects), to reduce runtime dependencies on crazy optional libraries (like SVGAlib). Damn, I wish XPLC was ready, it would just be perfect for the job...

There is so many things I would like to do with Quadra, like using ZIP files for resources (like Quake III Arena does), turning the underlying game library into nice XPLC components, etc...

If anyone wants to help, go ahead! :-)

(no subject)

Argh, gcc is so braindead at times... According to the man page:

-MD    Like `-M' but the dependency information is written
       to files with names made  by  replacing  `.o'  with
       `.d'  at the end of the output file names.  This is
       in   addition   to   compiling    the    file    as
       specified--`-MD' does not inhibit ordinary compila­
       tion the way `-M' does.

Except one detail: it doesn't do that. I use "-o foo/bar.o", so my output file is foo/bar.o. Replacing '.o' with '.d' should yield foo/bar.d, but no, bar.d comes out, putting all of the dependency files in the top level directory.

Nice.

The DEPENDENCIES_OUTPUT environment variable seems promising, but it can only take a single file as the target of the rule (I would like to make the dependency file itself a dependent, so that it is automatically updated).

Other than that, the nearly perfect dependency checking and amazing speed of non-recursive makefiles is incredible. If more people would try that, they'd ditch automake pretty quickly (or automake would be updated to create non-recursive makefiles, which would be even better!).

I say "nearly", because I still use a single dependency file, which I obviously don't rebuild every time, so it could get wrong. But it is very easy to get a perfect dependency build by simply removing the file to force the recomputation of dependencies.