This is a collection of comments various people have sent in. As I collect more, I'll add some organization, too.

manages multiple lists of numerics, modes, commands, etc.

I'm using AutoGen to assist in the building of my IRC daemon (********). Totally written from scratch, I needed a maintainable way to generate code from a simple to edit list of numerics, modes, commands etc. I originally wrote a short script to do the job, and that was soon obsoleted by a small (and dodgey) utility program. When the need arose for me to generate many different files I sought out a program like AutoGen and haven't looked back since.

AutoGen now generates large repetitive portions of code for me, and saves me hours in maintenance. I've even started to give AutoGen smaller jobs too, just because it makes certain aspects of the code more maintainable by keeping certain datasets centralised. I'm still getting used to using Scheme, however. While talking to other developers that seems to be the main reason they shy away from AutoGen, disappointingly. I'm still in the belief it's the best way to do it.

I only wish AutoGen had a built in function which could escape a string suitable for HTML/XML:

 ("<foo>" to "&lt;foo&gt;" etc)

then I'd be set :)

[[ see "html-escape-encode" or even "string-substitute" - ed ]]

separates the operational data from the implementation

I am using AutoGen in my pet project, and find one of its best points to be that it separates the operational data from the implementation.

Indulge me for a few paragraphs, and all will be revealed: In the manual, Bruce cites the example of maintaining command line flags inside the source code; traditionally spreading usage information, flag names, letters and processing across several functions (if not files). Investing the time in writing a sort of boiler plate (a template in AutoGen terminology) pays by moving all of the option details (usage, flags names etc.) into a well structured table (a definition file if you will), so that adding a new command line option becomes a simple matter of adding a set of details to the table.

So far so good! Of course, now that there is a template, writing all of that tedious optargs processing and usage functions is no longer an issue. Creating a table of the options needed for the new project and running AutoGen generates all of the option processing code in C automatically from just the tabular data. AutoGen in fact already ships with such a template... AutoOpts.

One final consequence of the good separation in the design of AutoGen is that it is retargetable to a greater extent. The egcs/gcc/fixinc/inclhack.def can equally be used (with different templates) to create a shell script (inclhack.sh) or a c program (fixincl.c).

This is just the tip of the iceberg. AutoGen is far more powerful than these examples might indicate, and has many other varied uses. I am certain Bruce or I could supply you with many and varied examples, and I would heartily recommend that you try it for your project and see for yourself how it compares to m4.

Enterprise Java Bean components

I'd like to thank you (and everybody else involved) for AutoGen, and I thought you might like to hear how it has been extremely useful to me. In my end-of-study work, I am developing Enterprise Java Bean components, and as everyone who's ever seen those knows, quite a lot of (redundant) code and XML is necessary to get them running.

I had been investigating several java-based graphical code generators for EJBs, but none of them worked well enough for me. So I started looking for more generic tools, allowing me more control over the generated code.

Having found AutoGen, I was pretty quickly able to generate code skeletons, XML deployment descriptors and utility classes. I can now very easily generate skeletons for EJB applications that export their business methods as SOAP calls (using Apache SOAP), and allow clients to do remote SOAP calls transparently through automatically generated proxy classes.

Now that my end-of-study work is nearing its end, I have to say that without AutoGen I would not have been able to stay on schedule. It has allowed me to do better work in a shorter time.

Thanks for a great tool, and keep up the good work!

Cheers,
Christian G.
Luxembourg
Europe

Finite Element Method Programs

First of all thank you for all your work on the wonderful AutoGen/AutoOpts . I'm just writing to let you know that we are using AutoOpts in our FEMKD project https://femdk.l5.pk.edu.pl/femdk. (In FEMDK we are trying to gather various tools to facilitate writing finite element method programs). I have developed the following pattern of using AutoOpts. One element of it is a set of standard options definitions. [These definitions are then sourced by the various program specific option definition files.] We have also incorporated calls to AutoGen into our CMake driven build process.

AutoOpts really helped me a lot

Well. Until now I haven't really used Autogen [[...]] But I have used AutoOpts and it really helped me a lot:

• easy to understand & implement (easier than argp for example)
• very well documented!!!
• it can do all I need and think of right now
• and if something doesn't work the way I want or doesn't exist at all, adding things is easy due to the clean code and good support by Bruce

-- Daniel

generating CGI pages

I thought I would give you an update. I have completely removed any connection between my programs and html, and instead pipe it all into autogen. I have a bunch of CGIs, and now they merely produce lists of name=value pairs, which are piped into autogen. It works excellently. I mentioned turning autogen into a standalone server in a previous message. Maybe someday, but I am in a big hurry, so for now my CGI writes to stdout when offline, and when online it uses popen to write into autogen, producing the html. The benefits have been tremendous.

Brian
NAS Division
NASA/Ames

dealing with config files and CLI options is quick and easy

I just wanted to take a few seconds to say thank you for autoopts. I'm in the process of having to write code to process a config file which is unfortunately in JSON and even with a decent parser library, it's still a very time consuming, bug prone and boring PITA. Makes me really appreciate just how easy and quick autoopts makes dealing with configuration files & CLI options so that I can spend my time working on the interesting problems!

Aaron