According to Alastair McKinstry on 3/28/2009 10:06 AM: > We use 'modules' to change our software environment on our system: > offering multiple versions of compilers, etc. > It is useful to track the software environment in the config.log when > software is built in this environment. To do this, > we use the following patch to add modules output. > > This can be added to the *.ac file for a package, but is better included > in the main systems definitions.
Thanks for the report; however, this is probably a better candidate for the Autoconf Macro Archive project until it is determined that there are enough users to warrant making it a core part of Autoconf. That said, here are some ideas for improving your macro. > > > # AC_MODULES_OUTPUT > # ----------------- > # Check if the system runs 'modules', and if so, record the modules > environment in the config.log > AC_DEFUN([AC_MODULES_LIST], Until this macro is made part of autoconf proper, I would highly suggest that you use a different namespace than AC_*, so that if Autoconf ever adds a macro by the same name but with different semantics, you won't have to change your code to deal with the collision. > [AC_CACHE_CHECK[modules output if present],[ac_modules_output], Your cache variable needs to be named with _cv_ in the name to be effective. Likewise, put your cache variable in the same namespace as your macro. > (ac_modules_output=`module list 2>&1`) > if test $? eq 0; then Forking a subshell is expensive. But you need one in order to silence some shell's 'not found' message, if 'module' is not on your path. On the other hand, your redirection occurs too late - if the file is not found, redirecting inside the `` does not silent that message. Why not simplify this: if (module list) >/dev/null 2>&1; then ac_module_list=`module list` else ac_module_list= fi > AC_MSG_RESULT([Output from 'module list' was:\n $ac_modules_output]) Using \n does not mean newline in AC_MSG_RESULT. If you want a newline, then use a literal newline. > fi > ]) > -- Eric Blake
