autoconf 2.62 is now released

Autoconf 2.62 has now been released.

I have been anticipating this release for more than a year now due to its support for openmp and a number of C99 compiler check enhancements.

This will be the last autoconf release under the GPL version 2; going forward we'll be seeing GPL version 3.

Spiffy.

Drafting software in the free world

So here at the new job with Rising Edge Engineering, I have been learning all about electrical drafting, document control and the meaning of life.

One of things that I see that is missing in the open source universe is suitable open source drafting software. Inkscape, and OpenOffice.org Draw are not designed for this stuff. So is there anything out there that can be used for something resembling real drafting...?

The other thing I see is missing is some sort of document control server that OO.o, inkscape, and other document apps can plug into to deal with revisions. It would be great to set up something that sits on top of ssh that is designed to deal with the various intricacies of document management stuff.

Really I want an end-to-end enterprise document creation/storage system.

Any Takers?

How soon is too soon?

I have a small confession to make.

I am unfortunately one of those folks that rather likes new features in their software...

Since I have been developing httperf, I been trying to find the balance between modern and historical features that I should reliably be able to depend on.

The httperf tool was primarily written in the late 1990's and probably was developed against the GCC 2.7 or some version of EGCS, in conjunction with the HP C compiler. Obviously, things have moved quite a bit since those days, with the EGCS/GCC merge, and now the most recent release of GCC 4.2.1. Moreover the auto-tools have taken big steps since those times. New elegant features abound, and I am very much tempted to use them.

But should I?

While openSUSE doesn't mind the bleeding edge of gcc 4.2.1 for the upcoming 10.3 release, the OpenBSD project will be sticking with the gcc 3.3.x compiler for a while. Moreover, some prominent users of httperf are still using FreeBSD 4.x with gcc 2.95.x.

This puts me in a vaguely tough position. For one, I believe that more modern compiler features can dramatically improve httperf on a whole. But this is counter balanced with the need to not alienate existing users that are locked to an older platform for the time being.

So my decision? No change... Sort of.

For the time being I will commit to maintaining existing (working) code enclosed in conditional compilation flags to make sure existing users can still use the software. Along side with this I am developing new functionality which I will try to integrate into the old code base as feature compatibility permits.

Check out httperf cvs

-Ted

autoconf and libtool wasting time checking for g++ and g77

While the gnu auto tools are certainly the best build system
configurators on the face of the planet, I can't help but be aggrivated
by the AC_PROG_LIBTOOL macro.

Supposedly this macro tells the build system how to configure itself to
link in libraries to a program, and for the most part it does the trick.

However, whenever I run the configure script to set up the build
environment, this macro tests for the presence and usability of a c++
and fortran compiler. It does this regardless of the fact that I am not
using c++ nor fortran and additionally not linking to a library written
in either of those two languages.

Not a big deal but it is certainly a waste of time (which becomes
readily apparent on my vanilla openbsd 386 with 16mb of ram).

Here's hoping unneccessary checks like this can be removed when libtool
2.0 roles into town.

-Ted