autogen-users — For software developers that use AutoGen in their projects

Re: [Autogen-users] Fwd: shipping the auto-generated files

[Nikos M. <nm...@gn...>]

After having it implemented, it looks quite ugly (because files are
removed from the distributed tarball and cannot be easily revived). Is
there a reason why autogen generated files cannot run with an
arbitrary libopts? I mean does the API of libopts change that often?
If not it may be a good idea to require regeneration of the files only
libopts API is different from the API used by autogen. Currently the
#error condition is on every difference in major or minor release
between libopts and autogen, and this is what causes the
inconvenience.

regards,
Nikos

On Wed, Nov 6, 2013 at 8:28 PM, Nikos Mavrogiannopoulos <nm...@gn...> wrote:
> On 11/06/2013 06:26 PM, Bruce Korb wrote:
>> On 11/06/13 01:32, Nikos Mavrogiannopoulos wrote:
>>> Hello,
>>>   I realized that is not easy to ship the auto-generated files of
>>> autogen. That is if I ship them and the user has a different version
>>> of libopts installed then he'll get something like::
>>> In file included from ocpasswd.c:31:0:
>>> ./ocpasswd-args.h:61:3: error: #error option template version
>>> mismatches autoopts/options.h header
>>
>> Yep.  You must ensure that the headers in the included library
>> are found *before* the system headers.  What does the compile
>> line look like?  If it has -I/usr/include before -I$top_builddir/libopts
>> you will definitely have a problem.  The link line should also have
>> $top_builddir/libopts/libopts.a in it.
>>
>>>   # error option template version mismatches autoopts/options.h header
>>>
>>> If I include the libopts in the package and force the program to use
>>> that and not the system one, then I have issues with people who have
>>> autogen and regenerate them.
>>
>> If they regenerate stuff, they must also ensure that they compile and link
>> against the relevant version of the library and headers.
>>
>>> Both cases are kind of ugly, and the only viable alternative seem to
>>> be to not ship them at all and require autogen in the target system.
>>
>> That might work if all target systems come out of a foundry
>> (is a distro).
>>
>>> This is of course is ugly for systems like *bsd that typically do not
>>> have a lot of gnu tools (and autogen requires guile etc).
>>>
>>> Is there any other cleaner solution to that, that I'm missing?
>>
>> If compiling with -I$top_builddir/libopts early on and linking with
>> $top_builddir/libopts/libopts.a does not work, I'd like to understand
>> why not. :)  That _ought_ to work...
>
> What I want to do is compile with system libopts if it exists and the
> included one otherwise. Things work when the included one is used, but I
> have the issue described above (incompatibility of auto-generated files)
> if a system one is detected. What I am thinking, could work would be to
> delete the auto-generated files if the system libopts is being used.
>
> Probably that could be achieved by checking NEED_LIBOPTS_DIR after the
> CHECK_LIBOPTS macro.
>
> regards,
> Nikos
>

Re: [Autogen-users] Fwd: shipping the auto-generated files

[Nikos M. <nm...@gn...>]

On 11/06/2013 06:26 PM, Bruce Korb wrote:
> On 11/06/13 01:32, Nikos Mavrogiannopoulos wrote:
>> Hello,
>>   I realized that is not easy to ship the auto-generated files of
>> autogen. That is if I ship them and the user has a different version
>> of libopts installed then he'll get something like::
>> In file included from ocpasswd.c:31:0:
>> ./ocpasswd-args.h:61:3: error: #error option template version
>> mismatches autoopts/options.h header
> 
> Yep.  You must ensure that the headers in the included library
> are found *before* the system headers.  What does the compile
> line look like?  If it has -I/usr/include before -I$top_builddir/libopts
> you will definitely have a problem.  The link line should also have
> $top_builddir/libopts/libopts.a in it.
> 
>>   # error option template version mismatches autoopts/options.h header
>>
>> If I include the libopts in the package and force the program to use
>> that and not the system one, then I have issues with people who have
>> autogen and regenerate them.
> 
> If they regenerate stuff, they must also ensure that they compile and link
> against the relevant version of the library and headers.
> 
>> Both cases are kind of ugly, and the only viable alternative seem to
>> be to not ship them at all and require autogen in the target system.
> 
> That might work if all target systems come out of a foundry
> (is a distro).
> 
>> This is of course is ugly for systems like *bsd that typically do not
>> have a lot of gnu tools (and autogen requires guile etc).
>>
>> Is there any other cleaner solution to that, that I'm missing?
> 
> If compiling with -I$top_builddir/libopts early on and linking with
> $top_builddir/libopts/libopts.a does not work, I'd like to understand
> why not. :)  That _ought_ to work...

What I want to do is compile with system libopts if it exists and the
included one otherwise. Things work when the included one is used, but I
have the issue described above (incompatibility of auto-generated files)
if a system one is detected. What I am thinking, could work would be to
delete the auto-generated files if the system libopts is being used.

Probably that could be achieved by checking NEED_LIBOPTS_DIR after the
CHECK_LIBOPTS macro.

regards,
Nikos

Re: [Autogen-users] Fwd: shipping the auto-generated files

[Bruce K. <bk...@gn...>]

On 11/06/13 01:32, Nikos Mavrogiannopoulos wrote:
> Hello,
>   I realized that is not easy to ship the auto-generated files of
> autogen. That is if I ship them and the user has a different version
> of libopts installed then he'll get something like::
> In file included from ocpasswd.c:31:0:
> ./ocpasswd-args.h:61:3: error: #error option template version
> mismatches autoopts/options.h header

Yep.  You must ensure that the headers in the included library
are found *before* the system headers.  What does the compile
line look like?  If it has -I/usr/include before -I$top_builddir/libopts
you will definitely have a problem.  The link line should also have
$top_builddir/libopts/libopts.a in it.

>   # error option template version mismatches autoopts/options.h header
>
> If I include the libopts in the package and force the program to use
> that and not the system one, then I have issues with people who have
> autogen and regenerate them.

If they regenerate stuff, they must also ensure that they compile and link
against the relevant version of the library and headers.

> Both cases are kind of ugly, and the only viable alternative seem to
> be to not ship them at all and require autogen in the target system.

That might work if all target systems come out of a foundry
(is a distro).

> This is of course is ugly for systems like *bsd that typically do not
> have a lot of gnu tools (and autogen requires guile etc).
>
> Is there any other cleaner solution to that, that I'm missing?

If compiling with -I$top_builddir/libopts early on and linking with
$top_builddir/libopts/libopts.a does not work, I'd like to understand
why not. :)  That _ought_ to work...

Cheers - Bruce

[Autogen-users] Fwd: shipping the auto-generated files

[Nikos M. <nm...@gn...>]

Hello,
 I realized that is not easy to ship the auto-generated files of
autogen. That is if I ship them and the user has a different version
of libopts installed then he'll get something like::
In file included from ocpasswd.c:31:0:
./ocpasswd-args.h:61:3: error: #error option template version
mismatches autoopts/options.h header
 # error option template version mismatches autoopts/options.h header

If I include the libopts in the package and force the program to use
that and not the system one, then I have issues with people who have
autogen and regenerate them.

Both cases are kind of ugly, and the only viable alternative seem to
be to not ship them at all and require autogen in the target system.
This is of course is ugly for systems like *bsd that typically do not
have a lot of gnu tools (and autogen requires guile etc).

Is there any other cleaner solution to that, that I'm missing?

regards,
Nikos

Re: [Autogen-users] GNU AutoGen Version 5.18.2/AutoOpts Version 40.1

[Richard S. <rm...@gn...>]

        [ To any NSA and FBI agents reading my email: please consider
        [ whether defending the US Constitution against all enemies,
        [ foreign or domestic, requires you to follow Snowden's example.

Congratulations on the new release.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: [Autogen-users] [PATCH] autogen: fix definition of MAXPATHLEN

[Bruce K. <bk...@gn...>]

And now, in the same place, is a pre-release of sharutils:

http://autogen.sourceforge.net/data/sharutils-4.13.6pre4.tar.xz

> Oops.  You are correct.
> http://autogen.sourceforge.net/data/autogen-5.18.2pre11.tar.xz
>
> will be available within 30 minutes.

Re: [Autogen-users] [PATCH] autogen: fix definition of MAXPATHLEN

[Bruce K. <bk...@gn...>]

> No matter whether size_t is known or not by the preprocessor (and not
> even by the actual compiler), the cast in preprocessor condition is a
> syntax error, hence the issue.

Oops.  You are correct.
http://autogen.sourceforge.net/data/autogen-5.18.2pre11.tar.xz

will be available within 30 minutes.

[Autogen-users] path to guile exe

[Bruce K. <bk...@gn...>]

Long ago and far away, I must have needed to ensure that the path to
the guile executable be added to PATH in the testing.  As far as I
know, the only place where "guile" gets invoked is in the configuration
step and then only within the "guile-config" script.  Therefore, I
am removing the insertion of that path into PATH for the testing
environment.  Having done so for me, it still "works for me" and I
believe it will work for you, too, and also eliminate a problem
where the lib prefix is different from the bin prefix.  ("clever"?)

So if this raises concerns, please try the latest pre-release:

   http://autogen.sourceforge.net/data/autogen-5.18.2pre10.tar.xz

thank you.  Cheers - Bruce

Re: [Autogen-users] Many tests failing due to value of LIBGUILE_PATH

[Bruce K. <bru...@gm...>]

On 10/14/13 10:10, Eric Bavier wrote:
> The real problem for most of these tests seems to be the use of
> "/usr/bin/tr" instead of just "tr", since tr might not be installed at
> in /usr/bin.

Yep.  I need to add:

  TR=`command -v tr`
  test -x "$TR" || die "'tr' program is missing"

and _then_ use $TR.  Thanks.

> Which executables are actually required for the tests?  Is it just the
> 'guile' executable?  If that's the case, I think configure should just
> declare a precious variable named GUILE.  If the builder is already
> passing the --with-libguile configure flags, it wouldn't be too much
> more to ask that they then set GUILE if "guile" isn't already in PATH.
> The configure and tests scripts wouldn't have to worry at all about PATH
> then.

I've been fiddling this thing for long enough now that I have no idea.
I very likely don't even invoke "guile" anymore, but I might. :)
That would make it _really_ pointless.

>> For now, I've not included --with-libguile-path just because of time.
>> Please try the new pre-release and if you have troubles, I'll try
>> to get to the "with" thing.
>
> With the additional patch I pasted above, the prerelease works fine.
> I'll try coding up the GUILE precious variable in configure, and send a
> patch if that works.

For that to be useful, you also have to find the "guile" invocation and
use the $GUILE.  I have my doubts that it is even used any more.  :(

Re: [Autogen-users] [PATCH] autogen: fix definition of MAXPATHLEN

[Bruce K. <bk...@gn...>]

On 10/13/13 10:34, Pino Toscano wrote:
> Hi,
>
> attached there is a patch for autogen to fix the definition of
> MAXPATHLEN when not defined already (either not directly or because
> PATH_MAX is not defined either).
>
> This caused a build failure in sharutils (which embeds the libopts part
> of autogen) on GNU/Hurd (which provides no PATH_MAX nor MAXPATHLEN) [1].
> This happens because in autogen's autoopts.h there is:
> #  if defined(PATH_MAX) && (PATH_MAX > MAXPATHLEN)
> which triggers a preprocessor parsing error when MAXPATHLEN is defined
> as (size_t)4096.

I think the correct fix would be to ensure that "size_t" is defined.

"size_t" is defined by <sys/types.h>, <unistd.h> and/or <stdio.h>, depending
on platform, and all are included before any attempt is made to hack around
MAXPATHLEN.  So what's going on on Hurd?  Is there a bug that "config.h"
is not included first?

Re: [Autogen-users] Many tests failing due to value of LIBGUILE_PATH

[Eric B. <ba...@cr...>]

Bruce Korb <bru...@gm...> writes:

> On 10/10/13 13:50, Eric Bavier wrote:
>> I was working on packaging AutoGen for Guix (www.gnu.org/software/guix)
>> and came across a number of failing tests with `make check` (19 of 24 in
>> autoopts failed).
>
> I am now wondering how that might have happened.
> The "init_tests" function should not be run with "set -e" active.
> Failing to test the results:
>
>>  f=`\cd ${LIBGUILE_PATH}/../bin && pwd`
>>  PATH=${f}:${PATH}
>
> should just lead to a spurious ":" appended to the start of $PATH.

Actually, it looks like you are right.  Looking at the test logs some
more, the hard errors do not occur until after this.

The real problem for most of these tests seems to be the use of
"/usr/bin/tr" instead of just "tr", since tr might not be installed at
in /usr/bin.

--- a/autoopts/test/defs.in
+++ b/autoopts/test/defs.in
@@ -289,7 +289,7 @@
   test "X${Cexe}"  = "X" && Cexe="${Csrc}"
   test "X${Dnam}"  = "X" && Dnam="${testname}"
 
-  d=`echo TEST_TEST_${Dnam}_OPTS | /usr/bin/tr '[a-z]-' '[A-Z]_'`
+  d=`echo TEST_TEST_${Dnam}_OPTS | tr '[a-z]-' '[A-Z]_'`
   cc_cmd="${CC} ${CFLAGS} -D$d ${INC} -o ${Cexe} ${Csrc}.c ${LIB}"
   eval ${cc_cmd} || \
     failure cannot compile ${Csrc}.c

> The following should be a little bit more rigorous:
>
>>   f=`\cd ${LIBGUILE_PATH}/../bin 1>/dev/null && pwd` || {
>>     f=`command -v guile | sed 's@/[^/]*$@@'`
>>     test -d "$f" || die "cannot find guile exe"
>>   }
>>   case ":${PATH}:" in
>>   *":${f}:"* ) : ;;
>>   * ) PATH=${f}:${PATH} ;;
>>   esac
>
> But "errexit" should still not be set.

Which executables are actually required for the tests?  Is it just the
'guile' executable?  If that's the case, I think configure should just
declare a precious variable named GUILE.  If the builder is already
passing the --with-libguile configure flags, it wouldn't be too much
more to ask that they then set GUILE if "guile" isn't already in PATH.
The configure and tests scripts wouldn't have to worry at all about PATH
then.

>
> For now, I've not included --with-libguile-path just because of time.
> Please try the new pre-release and if you have troubles, I'll try
> to get to the "with" thing.

With the additional patch I pasted above, the prerelease works fine.
I'll try coding up the GUILE precious variable in configure, and send a
patch if that works.

-- 
Eric Bavier, Scientific Libraries, Cray Inc.

Re: [Autogen-users] Many tests failing due to value of LIBGUILE_PATH

[Bruce K. <bru...@gm...>]

On 10/10/13 13:50, Eric Bavier wrote:
> I was working on packaging AutoGen for Guix (www.gnu.org/software/guix)
> and came across a number of failing tests with `make check` (19 of 24 in
> autoopts failed).

I am now wondering how that might have happened.
The "init_tests" function should not be run with "set -e" active.
Failing to test the results:

>  f=`\cd ${LIBGUILE_PATH}/../bin && pwd`
>  PATH=${f}:${PATH}

should just lead to a spurious ":" appended to the start of $PATH.
The following should be a little bit more rigorous:

>   f=`\cd ${LIBGUILE_PATH}/../bin 1>/dev/null && pwd` || {
>     f=`command -v guile | sed 's@/[^/]*$@@'`
>     test -d "$f" || die "cannot find guile exe"
>   }
>   case ":${PATH}:" in
>   *":${f}:"* ) : ;;
>   * ) PATH=${f}:${PATH} ;;
>   esac

But "errexit" should still not be set.

For now, I've not included --with-libguile-path just because of time.
Please try the new pre-release and if you have troubles, I'll try
to get to the "with" thing.

Thanks - Bruce

http://autogen.sourceforge.net/data/autogen-5.18.2pre7.tar.xz

Re: [Autogen-users] Many tests failing due to value of LIBGUILE_PATH

[Bruce K. <bru...@gm...>]

Hi Eric,

In the intervening years, I've forgotten how everything gets done.
That automation is part of how I limit what I have to remember :).
Anyway:

On Fri, Oct 11, 2013 at 7:03 AM, Eric Bavier <ba...@cr...> wrote:
> Also, I was wondering, since the problem is essentially that the the
> current method picks the wrong path from "-L${path1} -L${path2}",
> couldn't the configure macro do a loop over all paths and look for the
> one that has a bin directory containing the executables needed by
> autogen?

That would be a better solution.  Could I encourage you to code it up?
A patch is _so_ much easier to deal with.

Thank you!

Regards, Bruce

Re: [Autogen-users] Many tests failing due to value of LIBGUILE_PATH

[Eric B. <ba...@cr...>]

Bruce Korb <bru...@gm...> writes:

> On 10/10/13 13:50, Eric Bavier wrote:
>> Why not use LIBGUILE_PATH=`guile-config info libdir` instead?
>
> Because, cleverly, not all distributions distribute (install)
> guile-config.

I suggested the guile-config option because I saw that guile-config was
already being used in one of the configure paths.

> A better question is why doesn't Guile provide a guile.m4 file that derives
> all the information one might need?  They can supply it to gnulib, if they
> don't want to provide it themselves.

I can forward the question to the guile developers.

> Meanwhile, I will add --with-libguile-path that overrides the derived
> LIBGUILE_PATH value.

That should work, as long as you make the intent of the option clear
enough.


Also, I was wondering, since the problem is essentially that the the
current method picks the wrong path from "-L${path1} -L${path2}",
couldn't the configure macro do a loop over all paths and look for the
one that has a bin directory containing the executables needed by
autogen?

> Cheers - Bruce

-- 
Eric Bavier, Scientific Libraries, Cray Inc.

Re: [Autogen-users] Many tests failing due to value of LIBGUILE_PATH

[Bruce K. <bru...@gm...>]

On 10/10/13 13:50, Eric Bavier wrote:
> I was working on packaging AutoGen for Guix (www.gnu.org/software/guix)
> and came across a number of failing tests with `make check` (19 of 24 in
> autoopts failed).  The failure in most cases happened on line 126 of
> "autoopts/test/defs", which attempts to cd to ${LIBGUILE_PATH}/../bin.
> The failure occurs because the directory does not exist.
>
> It looks like ag_macros.m4 needs to have a better method of determining
> the value of LIBGUILE_PATH.  The current method takes the path of the
> last -L argument in LIBGUILE_LIBS.  For me, this path points to the
> libdir for libgc, which is not installed at the same --prefix as
> libguile itself, so we can't go to ${libgc-prefix}/lib/../bin because
> libgc doesn't install a bin directory.
>
> Why not use LIBGUILE_PATH=`guile-config info libdir` instead?

Because, cleverly, not all distributions distribute (install) guile-config.
A better question is why doesn't Guile provide a guile.m4 file that derives
all the information one might need?  They can supply it to gnulib, if they
don't want to provide it themselves.

Meanwhile, I will add --with-libguile-path that overrides the derived
LIBGUILE_PATH value.

Cheers - Bruce

[Autogen-users] Many tests failing due to value of LIBGUILE_PATH

[Eric B. <ba...@cr...>]

I was working on packaging AutoGen for Guix (www.gnu.org/software/guix)
and came across a number of failing tests with `make check` (19 of 24 in
autoopts failed).  The failure in most cases happened on line 126 of
"autoopts/test/defs", which attempts to cd to ${LIBGUILE_PATH}/../bin.
The failure occurs because the directory does not exist.

It looks like ag_macros.m4 needs to have a better method of determining
the value of LIBGUILE_PATH.  The current method takes the path of the
last -L argument in LIBGUILE_LIBS.  For me, this path points to the
libdir for libgc, which is not installed at the same --prefix as
libguile itself, so we can't go to ${libgc-prefix}/lib/../bin because
libgc doesn't install a bin directory.

Why not use LIBGUILE_PATH=`guile-config info libdir` instead?

-- 
Eric Bavier, Scientific Libraries, Cray Inc.

[Autogen-users] 5.18.1pre4 is available

[Bruce K. <bru...@gm...>]

It fixes several nuisance issues:

New in 5.18.1pre4 August 2013

* fixed char casting issue that shows in UTF-8 files
* fixed installation error for str2init
* fixed failure handling in the usage template
* various tweaks to make Coverity happy.

http://autogen.sourceforge.net/data/autogen-5.18.1pre4.tar.xz

[Autogen-users] Typo in 5.18 "preceeding"

[Andreas M. <ame...@do...>]

Hello,

find attached a trivial patch to fix a typo in autogen 5.18.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: [Autogen-users] GNU AutoGen Version 5.18/AutoOpts Version 40.0

[Richard S. <rm...@gn...>]

        [ To any NSA and FBI agents reading my email: please consider
        [ whether defending the US Constitution against all enemies,
        [ foreign or domestic, requires you to follow Snowden's example.

Congratulations on the new release.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: [Autogen-users] AutoOpts shell-process usage

[Bruce K. <bk...@gn...>]

On 07/04/13 06:45, Oliver Kindernay wrote:
> Thanks, works nice. Do you have an idea when it will be available in
> stable release?

When it seems to be stable :)
Actually, I think Harlan/NTP gives it its worst beating.
Let's let it sit around for a couple of weeks and see if
anyone stubs their toe.  "works for me".

Cheers - Bruce

http://autogen.sourceforge.net/announce.html
http://autogen.sourceforge.net/data/autogen-5.17.5pre8.tar.xz

Re: [Autogen-users] AutoOpts shell-process usage

[Bruce K. <bk...@gn...>]

On 07/02/13 17:02, Oliver Kindernay wrote:
> Hi,
>
> I am using AutoOpts for shell scripts (shell-process main). When the
> program is passed -? or --help it output usage to stdout and exits with
> return value 0, the same thing it does when emitting shell code after
> successful command line parsing. When following documentation, using the
> eval builtin like this
>
>      eval "`script-opts \"$@\"`"
>      test -z "${OPTION_CT}" && exit 1
>      test ${OPTION_CT} -gt 0 && shift ${OPTION_CT}
>
> since it's not easy to clearly distinguish between help invocation and
> successful command line parsing the eval just errors on usage output if
> we pass -? to this script.
>
> There can be multiple ways to solve this, for example we can distinguish
> usage invocation by a different exit value.
>
> I have made a two patches, one that passes failure exit code to
> optionUsage(), making it output to stderr. I am not sure the program
> should exit with failure exit code though, so I made the second patch,
> which uses success exit code, but outputs to stderr. I am using
> option_usage_fp global and I am not sure this is documented behaviour
> and correct way to do this.
>
> Both of these patches make the eval work without error when the parser
> is passed -? or --help.
>
> What do you think?

Hi,

I think you hit upon something not fully considered and never bothered me.
"eval"-ing usage text will make the shell unhappy.  It needs fixing.
You are correct that the actual exit code is not important for this
situation, but it is necessary for "normal" applications where the
program logic is in the same process as the option processing.
So, basically, we need to do normal usage processing, but send output
to stderr because stdout is being captured and eval-ed.

I think, additionally, we ought to emit "exit 0" to stdout as well,
eliminating the need for the test && exit.  I think the best solution
is to fiddle "doUsageOpt()" such that when it is called in this context,
it will print "exit 0\n" to stdout, redirect stdout to stderr and then
process the usage normally.

Thank you for pointing this out.

Regards, Bruce

[Autogen-users] Documentation options

[Bruce K. <bru...@gm...>]

I'm sure most all of you are aware of them -- these not-really-an-option options
are used to group options.  They are visible in usage text, man/mdoc pages
as well as the emitted texi documentation.  However, there was a little problem.
The options supported automatically were munged together with the final group
of program options unless the last program option was a documentation option.
*Except* that they were handled quite differently for texi output.

Unless someone squawks and suggests a better solution, the texi output template
will now swallow and ignore the last specified documentation option.  This way,
the texi doc will no longer have an empty subsection generated and you can still
introduce the "help", "version", "load-opts" etc. options with a "documentation"
option.

Please experiment with your projects and make sure it does not mess anything up.
Thank you!

Regards, Bruce

http://autogen.sourceforge.net/data/autogen-5.17.5pre5.tar.xz

There are also a couple of fairly obscure cleanups and enhancements:
http://autogen.sourceforge.net/announce.html

[Autogen-users] GNU AutoGen Version 5.17.4/AutoOpts Version 39.0

[Bruce K. <bk...@gn...>]

GNU AutoGen/AutoOpts is a two-part project that serves two separate
purposes.  The two parts are combined because they are inextricably
intertwined:

AutoGen is a tool designed to simplify the creation and maintenance of
programs that contain large amounts of repetitious text.  It is
especially valuable in programs that have several blocks of text that
must be kept synchronized.

AutoOpts is both an example of that and a project in its own right.
It is a very powerful configuration file, environment variable and
command line option documentation and management tool consisting of a
set of AutoGen templates and a run time library that nearly eliminates
the hassle of managing, parsing and documenting program options.

The self-referential example:
http://www.gnu.org/software/autogen/man1-autogen.html

There are several other examples embedded in AutoGen:
A finite state machine generator, string name to enumeration value
conversions, and bit map and bit mask management, to name a few.

New in 5.17.4 - May, 2013
NEWS entries since the last release:

* --save-opts documentation cleanup
* optionMemberList() will return an allocated string containing
   the names of the bits set in the option.
* OPT_MEMLST_option_name is a new macro that invokes that function
   for "option_name"
* Set membership strings are now more forgiving in their syntax.
   See "Arg Type Set Membership" in the docs.
* tab stripped "here strings" include stripping the backslash
   escape character when it precedes any whitespace character.

AutoGen home:    http://www.gnu.org/software/autogen/
primary ftp:     ftp://ftp.gnu.org/gnu/autogen/rel5.17.4/
.tar.gz:         ftp://ftp.gnu.org/gnu/autogen/rel5.17.4/autogen-5.17.4.tar.gz
.tar.xz:         ftp://ftp.gnu.org/gnu/autogen/rel5.17.4/autogen-5.17.4.tar.xz
bug reports:     autogen-users at the lists dot SourceForge net domain
bug archive:     http://sourceforge.net/mailarchive/forum.php?forum_name=autogen-users
maintainer:      Bruce Korb - bkorb at the usual GNU domain

Re: [Autogen-users] error when running make — using autogen generated makefile

[Harlan S. <st...@nt...>]

allan George writes:
> Hi,
> 
> I am trying to compile a websocket package, procedure used is :--
> ./autogen
> ./configure
> make

Different autogen.

The one you have is not GNU Autogen - it is a script with a name that
conflicts with the autogen  package here, so you should ask whoever
maintains the package you are trying to build about this.

H

[Autogen-users] Autogen 5.17.4 pre-announcement

[Bruce K. <bru...@gm...>]

This release is mostly to facilitate use of set membership options.
New libopts function --> revision bump.

New in 5.17.4pre10 May 2013

* --save-opts documentation cleanup
* optionMemberList() will return an allocated string containing
   the names of the bits set in the option.
* OPT_MEMLST_option_name is a new macro that invokes that function
   for "option_name"
* Set membership strings are now more forgiving in their syntax.
   See "Arg Type Set Membership" in the docs.