JeffJournal

How many times have you gotten the SirCam worm?

I think I've gotten it at least a dozen times, twice of which were in spanish.

I was just notified by the Army that I go before the promotion board for Captain in November. How funny is that?

I am immensely amused. I can't imagine that I'll get it; I'm quite sure that there are many other 1LT's ahead of me who are more deserving of a CPT slot. But I still find it damn funny.

:-)

Playing with new autoconf (ver 2.52), automake (ver 1.5-p4), and libtool (ver 1.4). Here's some things that I've learned:

• It's not too painful to move to the new autoconf. There's a few macros that have to be changed (e.g., AC_INIT has a new arg list), and some of the macros that I use frequently have been deprecated in favor of new ones, but the transformations are mostly straightforward.

• There's some new handy fortran macros that will help in LAM/MPI.

• Remember how the line you invoked configure with used to be in config.status? It's not there anymore. Doh!

• Not to worry, though, the line that you used to invoke configure with is now in config.log (I don't know why they moved it). In general, config.log is now much easier to read, and has lots more information in it that will be valuable to both sysadmins and programmers.

• "configure --help" has lots more information in it.

• AC_OUTPUT is now effectively broken into multiple macros; AC_OUTPUT itself just triggers finishing the write of config.status and then runs it. AC_CONFIG_FILES, AC_CONFIG_HEADERS, AC_CONFIG_COMMANDS, and AC_CONFIG_LINKS are now how you specify the output files, output header files, commands to run in and around output time, and sym links to make.

• "acconfig.h" is now obsolete. There's a handful of new "AH_" autoheader macros that you put in configure.in to put in the top and bottom portions of the header file. You also have to specify "templates" for each #define with AH_TEMPLATE. I'm not sure how I feel about that one. :-\

• Some cool new macros that will rapidly become my favorites:

  • AC_ARG_VAR: Mark a shell variable as "precious", list it in the output of "configure --help" and save its value in config.status. Warn if the value stored in config.status doesn't match the present value (in case you run config.status at a later date).

  • AC_HELP_STRING: Automatically format the strings that you give to AC_ARG_WITH and AC_ARG_ENABLE to get that pesky spacing right.

  • AC_SUBST_FILE: Allows you to do the same thing as AC_SUBST, but substitute in the contents of a file. I see
    $COPYRIGHT$ potential here...

  • AC_CHECK_DECL: Checks to see if a symbol is declared. I've always had my own tests for this; I'll be happy to start using this macro instead of my own.

  • AC_CHECK_MEMBER: Check whether a struct or class has a given member or not.
    
  
  

All in all, it looks like they tried to add significant useful functionality to autoconf, so I'm overall pleased.

HOWEVER, it caused me an hour of two of frustration before I finally tracked down a problem with libtool -- there's a bug in the libtool 1.4 distribution. If you use AC_CONFIG_AUX_DIR to put all your config files in a subdirectory rather than the top-level directory (which I do), and if you use configure.ac instead of configure.in, libtool will get corn-fuzed and put ltmain.sh, config.guess, and config.sub in the top-level directory instead of your config directory. This eventually causes much badness... no need to discuss specifics here.

The problem is in the "libtoolize" script -- there's one place where "configure.in" is still hard-coded in, instead of using "$configure_ac", which is set to the Right value.

This has apparently been fixed in the libtool CVS (I checked), so the next version will have this correct. Ugh.

That's enough for now. Time to go mow the lawn.