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

Re: [Autogen-users] autoopt and Windows . . .

[Geof S. <Geo...@ut...>]

Hi Aaron,

Thanks for your pointers on this, and congrats on your tcpreplay project.

I'm attempting to do this on the MinGW path so that we can distribute without Cygwin dependencies . . .

I'll let you know how it goes!

Geof



> -----Original Message-----
> From: Aaron Turner [mailto:syn...@gm...]
> Sent: Wednesday, October 07, 2009 11:09 AM
> Cc: Geof Sawaya; autogen
> Subject: Re: [Autogen-users] autoopt and Windows . . .
> 
> On Wed, Oct 7, 2009 at 7:32 AM, Bruce Korb <bk...@gn...> wrote:
> > Hi Geof,
> >
> > On Tue, Oct 6, 2009 at 8:52 PM, Geof Sawaya <Geo...@ut...>
> wrote:
> >> Hi Bruce,
> >>
> >> I have our Linux build working fine, your suggestions made it much
> cleaner.
> >>
> >> But our project also includes a Windows build.
> >> It appears that I'm clueless on how to build the libopt library for
> Windows.
> >>
> >> After tweaking #includes (including adding windows-config.h to *-
> opts.h)
> >>  and commenting out windows-config.h: typedef unsigned long
> uintptr_t
> >> (because it is defined in VC/include/vadefs.h, and the types look
> similar),
> >
> > I can fix the configure script to cope with this.
> > I wish I could understand why MSoft had to go find new and better
> > headers for stashing stuff like that.  :(
> >
> >>  I'm getting unresolved linker errors on optionProcess and my
> *Options
> >> struct.
> >>
> >> Can you give me an easy recipe to build this?
> >
> > Unfortunately, I cannot.  Hopefully, someone on the users list may
> have
> > some good suggestions.  I do not use Windows myself.
> 
> Geof,
> 
> I'm not a big windows user by anymeans, but I have been able to build
> autogen & use autoopts under Windows w/ Cygwin via gcc in my own
> project.  Doesn't seem to be any way to build it natively under
> Windows though that I'm aware of.
> 
> I documented the steps necessary to get Autogen working properly under
> Cygwin here:
> http://tcpreplay.synfin.net/trac/browser/trunk/docs/Win32Readme.txt
> 
> Code which compiles under Cygwin is here:
> http://tcpreplay.synfin.net/trac/browser/branches/3.4
> 
> and is available via svn:
> 
> https://www.synfin.net/svn/tcpreplay/branches/3.4
> 
> Honestly, I never had to do anything like you're describing above so I
> don't have a good answer for you.
> 
> --
> Aaron Turner
> http://synfin.net/
> http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix &
> Windows
> Those who would give up essential Liberty, to purchase a little
> temporary
> Safety, deserve neither Liberty nor Safety.
>     -- Benjamin Franklin

Re: [Autogen-users] autoopt and Windows . . .

[Aaron T. <syn...@gm...>]

On Wed, Oct 7, 2009 at 7:32 AM, Bruce Korb <bk...@gn...> wrote:
> Hi Geof,
>
> On Tue, Oct 6, 2009 at 8:52 PM, Geof Sawaya <Geo...@ut...> wrote:
>> Hi Bruce,
>>
>> I have our Linux build working fine, your suggestions made it much cleaner.
>>
>> But our project also includes a Windows build.
>> It appears that I’m clueless on how to build the libopt library for Windows.
>>
>> After tweaking #includes (including adding windows-config.h to *-opts.h)
>>  and commenting out windows-config.h: typedef unsigned long uintptr_t
>> (because it is defined in VC/include/vadefs.h, and the types look similar),
>
> I can fix the configure script to cope with this.
> I wish I could understand why MSoft had to go find new and better
> headers for stashing stuff like that.  :(
>
>>  I’m getting unresolved linker errors on optionProcess and my *Options
>> struct.
>>
>> Can you give me an easy recipe to build this?
>
> Unfortunately, I cannot.  Hopefully, someone on the users list may have
> some good suggestions.  I do not use Windows myself.

Geof,

I'm not a big windows user by anymeans, but I have been able to build
autogen & use autoopts under Windows w/ Cygwin via gcc in my own
project.  Doesn't seem to be any way to build it natively under
Windows though that I'm aware of.

I documented the steps necessary to get Autogen working properly under
Cygwin here:
http://tcpreplay.synfin.net/trac/browser/trunk/docs/Win32Readme.txt

Code which compiles under Cygwin is here:
http://tcpreplay.synfin.net/trac/browser/branches/3.4

and is available via svn:

https://www.synfin.net/svn/tcpreplay/branches/3.4

Honestly, I never had to do anything like you're describing above so I
don't have a good answer for you.

-- 
Aaron Turner
http://synfin.net/
http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix & Windows
Those who would give up essential Liberty, to purchase a little temporary
Safety, deserve neither Liberty nor Safety.
    -- Benjamin Franklin

Re: [Autogen-users] autoopt and Windows . . .

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

Hi Geof,

On Tue, Oct 6, 2009 at 8:52 PM, Geof Sawaya <Geo...@ut...> wrote:
> Hi Bruce,
>
> I have our Linux build working fine, your suggestions made it much cleaner.
>
> But our project also includes a Windows build.
> It appears that I’m clueless on how to build the libopt library for Windows.
>
> After tweaking #includes (including adding windows-config.h to *-opts.h)
>  and commenting out windows-config.h: typedef unsigned long uintptr_t
> (because it is defined in VC/include/vadefs.h, and the types look similar),

I can fix the configure script to cope with this.
I wish I could understand why MSoft had to go find new and better
headers for stashing stuff like that.  :(

>  I’m getting unresolved linker errors on optionProcess and my *Options
> struct.
>
> Can you give me an easy recipe to build this?

Unfortunately, I cannot.  Hopefully, someone on the users list may have
some good suggestions.  I do not use Windows myself.

Regards, Bruce

Re: [Autogen-users] 'extract' Function Sets Output Files Writable - Feature, not Bug.

[Eric M. <mcd...@ph...>]

Thanks for the explanation, Bruce. What you say does make sense from the
perspective you were approaching it.

I guess I was approaching it from a slightly different angle (i.e.,
pulling in pieces of other files to create a generated, non-editable
"Frankenfile"). Maybe there is a better approach for what I am trying to
do. (There is no definitions file for the use case I have in mind - just
portions of a bunch of other generated files to merge with the
template.) However, it looks like --not-writable will do the trick. Thanks.

Regards,
  Eric

Bruce Korb wrote:
> On Sat, Oct 3, 2009 at 4:00 PM, Eric McDonald <mcd...@ph...> wrote:
>> Hi,
>>
>>  I've noticed that the output files from templates, which use the
>> 'extract' Autogen Scheme function, are set to writable. Looking at the
>> 'loadExtractData' function in agen5/expExtract.c, I can see that this
>> appears to be deliberate:
>>
>>      if (! HAVE_OPT( WRITABLE ))
>>        SET_OPT_WRITABLE;
>>
>> I am having trouble understanding why this is desirable. I read the
>> documentation for the 'extract' function, as well as the comments in its
>> implementation, and nothing really stands out as a reason. Even if the
>> output files are not going to be kept around long-term, as in the case
>> of the example code mentioned in the documentation, they should still be
>> able to get forcefully renamed or removed. Hence, it should be safe to
>> leave them read-only by default.
>>
>>  Any insights?
> 
> The theory behind it is that if you are extracting something from the previous
> incarnation of the same file, then your client wants to be able to edit the
> text that was extracted.  Witness the file agen5/cgi-fsm.c:
> 
>         case CGI_TR_NAME_EQUAL:
>             /* START == NAME_EQUAL == DO NOT CHANGE THIS COMMENT */
>             strcpy( pzOut, "='" );
>             outlen -= 2;
>             pzOut += 2;
>             /* END   == NAME_EQUAL == DO NOT CHANGE THIS COMMENT */
>             break;
> 
> The code between the "START" and "END" is hand crafted.
> The rest changes if my FSM state machine template changes.
> This is in line with what is done by GUI code generators, for example.
> If you use the option, ``--not-writable'', then loadExtractData will not
> force the output to be writable.  (You "have" the option and it was set
> to the disabled state.)
> 
> I will augment the doc for "extract".  Thanks!  Regards, Bruce

Re: [Autogen-users] 'extract' Function Sets Output Files Writable - Feature, not Bug.

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

On Sat, Oct 3, 2009 at 4:00 PM, Eric McDonald <mcd...@ph...> wrote:
> Hi,
>
>  I've noticed that the output files from templates, which use the
> 'extract' Autogen Scheme function, are set to writable. Looking at the
> 'loadExtractData' function in agen5/expExtract.c, I can see that this
> appears to be deliberate:
>
>      if (! HAVE_OPT( WRITABLE ))
>        SET_OPT_WRITABLE;
>
> I am having trouble understanding why this is desirable. I read the
> documentation for the 'extract' function, as well as the comments in its
> implementation, and nothing really stands out as a reason. Even if the
> output files are not going to be kept around long-term, as in the case
> of the example code mentioned in the documentation, they should still be
> able to get forcefully renamed or removed. Hence, it should be safe to
> leave them read-only by default.
>
>  Any insights?

The theory behind it is that if you are extracting something from the previous
incarnation of the same file, then your client wants to be able to edit the
text that was extracted.  Witness the file agen5/cgi-fsm.c:

        case CGI_TR_NAME_EQUAL:
            /* START == NAME_EQUAL == DO NOT CHANGE THIS COMMENT */
            strcpy( pzOut, "='" );
            outlen -= 2;
            pzOut += 2;
            /* END   == NAME_EQUAL == DO NOT CHANGE THIS COMMENT */
            break;

The code between the "START" and "END" is hand crafted.
The rest changes if my FSM state machine template changes.
This is in line with what is done by GUI code generators, for example.
If you use the option, ``--not-writable'', then loadExtractData will not
force the output to be writable.  (You "have" the option and it was set
to the disabled state.)

I will augment the doc for "extract".  Thanks!  Regards, Bruce

[Autogen-users] 'extract' Function Sets Output Files Writable - Feature or Bug?

[Eric M. <mcd...@ph...>]

Hi,

  I've noticed that the output files from templates, which use the
'extract' Autogen Scheme function, are set to writable. Looking at the
'loadExtractData' function in agen5/expExtract.c, I can see that this
appears to be deliberate:

      if (! HAVE_OPT( WRITABLE ))
        SET_OPT_WRITABLE;

I am having trouble understanding why this is desirable. I read the
documentation for the 'extract' function, as well as the comments in its
implementation, and nothing really stands out as a reason. Even if the
output files are not going to be kept around long-term, as in the case
of the example code mentioned in the documentation, they should still be
able to get forcefully renamed or removed. Hence, it should be safe to
leave them read-only by default.

  Any insights?

Thanks,
  Eric

[Autogen-users] debugging autogen w/ gdb

[Aaron T. <syn...@gm...>]

So I had a lot of fun yesterday debugging a strange problem with
autoopts- I'd pass options on the CLI, but they wouldn't be detected
as "set".

ie:

if (HAVE_OPT(FOO)) {
   # do something with FOO
}

would return false, even if --foo was passed.

Long story short, the problem ended up having nothing to do with my C
code or a bug in autoopts (it was a problem with automake), but it was
difficult to debug since I couldn't figure out how to get gdb to
provide any information on FOO.

things like:

p FOO
p HAVE_OPT(FOO)

all returned errors in gdb about unknown symbols or something like
that.  Can anyone share the trick?

Thanks,
Aaron

-- 
Aaron Turner
http://synfin.net/
http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix & Windows
Those who would give up essential Liberty, to purchase a little temporary
Safety, deserve neither Liberty nor Safety.
    -- Benjamin Franklin

[Autogen-users] AutoGen GSoC project

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

The NTP Project has been accepted by Google's Summer of Code project for
2009, and one of of the project I'd really like to see get implemented
is an improvement to AutoGen's documentation capabilities.

This project is described at:

 https://support.ntp.org/bin/view/Dev/GoogleSummerOfCode

and

 https://support.ntp.org/bin/view/Dev/GSoC2008doc

If there are any students here who are willing, capable, and interested
in working on this project, please let me know.
-- 
Harlan Stenn <st...@nt...>
http://ntpforum.isc.org  - be a member!

[Autogen-users] subscribe

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

-- 
Harlan Stenn <st...@nt...>
http://ntpforum.isc.org  - be a member!

[Autogen-users] help

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

-- 
Harlan Stenn <st...@nt...>
http://ntpforum.isc.org  - be a member!

[Autogen-users] AutoGen GSoC project

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

The NTP Project has been accepted by Google's Summer of Code project for
2009, and one of of the project I'd really like to see get implemented
is an improvement to AutoGen's documentation capabilities.

This project is described at:

 https://support.ntp.org/bin/view/Dev/GoogleSummerOfCode

and

 https://support.ntp.org/bin/view/Dev/GSoC2008doc

If there are any students here who are willing, capable, and interested
in working on this project, please let me know.
-- 
Harlan Stenn <st...@nt...>
http://ntpforum.isc.org  - be a member!

Re: [Autogen-users] autogen intallation

[Aaron T. <syn...@gm...>]

On Tue, Mar 3, 2009 at 11:45 AM, Costas Vlachidis <cv...@ly...> wrote:
> Hi
> I have just downloaded the latest version of Autogen and unpacked it to my desktop of my Ubundu distribution.
> Now, since I'm new in Linux, please inform me on how to install it since I want to use it with the Anjunta IDE to build some C-C++ projects.
> Thanx Costas

Autogen uses the standard GNU autoconf/autotools build system.  Hence,
like most Linux apps, the process is:

./configure
make
make install  # as root

All this is documented in the INSTALL file included with the source code.

-- 
Aaron Turner
http://synfin.net/
http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix & Windows
Those who would give up essential Liberty, to purchase a little
temporary Safety,
deserve neither Liberty nor Safety.
    -- Benjamin Franklin

[Autogen-users] autogen intallation

[Costas V. <cv...@ly...>]

Hi
I have just downloaded the latest version of Autogen and unpacked it to my desktop of my Ubundu distribution.
Now, since I'm new in Linux, please inform me on how to install it since I want to use it with the Anjunta IDE to build some C-C++ projects.
Thanx Costas

[Autogen-users] Using libopts tearoff w/ Cmake

[Aaron T. <syn...@gm...>]

Long story short, I'm in the process of switching from Autotools to
Cmake (www.cmake.org) and to do a complete port, I wrote the necessary
cmake code to do compatibility testing & build the libopts tearoff.
While I wouldn't consider this fully tested, it does compile/link for
me on OSX and CentOS4.

I figured it might be interesting enough to add to the tearoff or
package up for other people considering using Cmake.

Attachments:
- CheckLibopts.cmake  - cmake module to test platform capabilities.
- CMakeLists.txt - Cmake file for libopts tearoff
- config.h.cmake - config.h template for cmake

Users will need to call something like:
IF(USE_LIBOPTS)
    message(STATUS "Configuring libopts tearoff...")
    INCLUDE(CheckLibopts)
    CHECK_LIBOPTS_TEAROFF(${CMAKE_SOURCE_DIR}/libopts 5.9.7)
ELSE(USE_LIBOPTS)
    message(STATUS "Skipping libopts tearoff")
ENDIF(USE_LIBOPTS)

and then add: ${CMAKE_SOURCE_DIR}/libopts/libopts.a

to their list of TARGET_LINK_LIBRARIES

There's a good chance that my code will change in the future (I'm
still working on various cmake things), but I'll be sure to send
updates for any major changes.

-- 
Aaron Turner
http://synfin.net/
http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix & Windows
Those who would give up essential Liberty, to purchase a little
temporary Safety,
deserve neither Liberty nor Safety.
    -- Benjamin Franklin

[Autogen-users] Some tests failing on openbsd

[Wim L. <wi...@hh...>]

A few of the tests are failing when I build autogen/autoopts on OpenBSD
4.4 (on an otherwise run-of-the-mill x86 system). I checked a few older
versions as well, and 5.9.4 through 5.9.7 all seem to fail the same way.
The failure that seems odd to me is in enums.test, which fails like this:

> creating enums.hlp
> FAILURE: 24c24
> <   or an integer between 0 and 9
> ---
> >   or an integer from 1 through 10
> 29c29
> <   or an integer between 0 and 15
> ---
> >   or an integer mask with any of the lower 16 bits set
> FAIL: enums.test

Although I'm not too familiar with autoopts, it looks to me like the test
is in error, and the generated help file is what it should be --- but if
that were the case, presumably someone else would have noticed this error
by now... So I assume there must be something peculiar to my setup.
Any ideas? Which of those messages is really correct?

The other test failure looks innocuous, though it makes 'make check'
unhappy. Starting in version 5.9.5, nested.test and cfg-edit.test fail
with a mismatch like this one:

> creating nested-base.help
> FAILURE: 15c15
> <  - reading file nested.d/nested.cfg
> ---
> >  - reading file /usr/ports/devel/autogen/w-autogen-5.9.6p0/autogen-5.9.6/autoopts/test/testdir/nested.d/nested.cfg
> FAIL: nested.test

that is, the test is emitting an absolute path where the .test file expects
a relative path.

I've tarred up the tests/FAILURES/ directory and put it at this url,
in case it's useful:
   http://underhill.hhhh.org/~wiml/misc/autoopts-597-failures.tar.gz

-- 
   Wim Lewis <wi...@hh...>, Seattle, WA, USA. PGP keyID 27F772C1
  "We learn from history that we do not learn from history." -Hegel

Re: [Autogen-users] 5.9.7 - tearoff and redefined types

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

Woops.  Sorry about that.  I'll go looking for my mistake.  Thank you.
 Have a happy new year!  Regards, Bruce

On Thu, Jan 1, 2009 at 2:59 PM, Aaron Turner <syn...@gm...> wrote:
> Looks like the libopts tearoff included in Autogen 5.9.7 is missing
> the necessary code to detect wint_t and size_t in the m4/libopts.m4
> code.  I ended up stealing the following lines from snprintfv.m4 and
> adding it to my base configure.ac to remove the errors:
>
> AC_CHECK_TYPES(size_t)
>
>
> # ----------------------------------------------------------------------
> # check for various programs used during the build.
> # On OS/X, "wchar.h" needs "runetype.h" to work properly.
> # ----------------------------------------------------------------------
> AC_CHECK_HEADERS([runetype.h wchar.h], [], [],[
> AC_INCLUDES_DEFAULT
> #if HAVE_RUNETYPE_H
> # include <runetype.h>
> #endif
> ])
>
> # ----------------------------------------------------------------------
> # Checks for typedefs
> # ----------------------------------------------------------------------
> AC_CHECK_TYPES(wchar_t)
> AC_CHECK_TYPES(wint_t, [], [], [
> AC_INCLUDES_DEFAULT
> #if HAVE_RUNETYPE_H
> # include <runetype.h>
> #endif
> #if HAVE_WCHAR_H
> # include <wchar.h>
> #endif
> ])
>
>
>
> --
> Aaron Turner
> http://synfin.net/
> http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix & Windows
> They that can give up essential liberty to obtain a little temporary
> safety deserve neither liberty nor safety.  -- Benjamin Franklin
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Autogen-users mailing list
> Aut...@li...
> https://lists.sourceforge.net/lists/listinfo/autogen-users
>

[Autogen-users] 5.9.7 - tearoff and redefined types

[Aaron T. <syn...@gm...>]

Looks like the libopts tearoff included in Autogen 5.9.7 is missing
the necessary code to detect wint_t and size_t in the m4/libopts.m4
code.  I ended up stealing the following lines from snprintfv.m4 and
adding it to my base configure.ac to remove the errors:

AC_CHECK_TYPES(size_t)


# ----------------------------------------------------------------------
# check for various programs used during the build.
# On OS/X, "wchar.h" needs "runetype.h" to work properly.
# ----------------------------------------------------------------------
AC_CHECK_HEADERS([runetype.h wchar.h], [], [],[
AC_INCLUDES_DEFAULT
#if HAVE_RUNETYPE_H
# include <runetype.h>
#endif
])

# ----------------------------------------------------------------------
# Checks for typedefs
# ----------------------------------------------------------------------
AC_CHECK_TYPES(wchar_t)
AC_CHECK_TYPES(wint_t, [], [], [
AC_INCLUDES_DEFAULT
#if HAVE_RUNETYPE_H
# include <runetype.h>
#endif
#if HAVE_WCHAR_H
# include <wchar.h>
#endif
])



-- 
Aaron Turner
http://synfin.net/
http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix & Windows
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.  -- Benjamin Franklin

[Autogen-users] autoopts dilemma

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

Hi,

It seems that the first user to use the AutoOpts templates but not
the libopts library has come along.  (You do this with the getopt.tpl
template.)  It seems the usage text and docs all assume the library
because without the library, there's no support for ``--more-help'',
but it is still documented.  I was thinking of adding the ``no-more-help''
program attribute for option definitions.  Cute, because it is both
true and not true at the same time.  Maybe, ``no-libopts'' would
be better.   I plan on addressing the issue in my next release,
probably before the end of the month/year.

Cheers -Bruce

Re: [Autogen-users] Autogen test failures

[Eric B. <eb...@by...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Bruce Korb on 12/6/2008 4:06 PM:
> Hi Ali,
> 
> It looks like you did a "make check" before "make install" and a couple
> of tests failed.

Per the GNU Coding Standards, 'make check' is _supposed_ to work on an
uninstalled package.  If you want to test the installed package, you use
'make installcheck'.  If autogen requires 'make install' before 'make
check' will work, this is a bug in autogen.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             eb...@by...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkk7CIYACgkQ84KuGfSFAYA/WgCbB1Vwq978/uZM8mbUPn/t6uLk
g7EAn3uoEakStAYRBtv1qncSuo+jBq1C
=isfn
-----END PGP SIGNATURE-----

[Autogen-users] Autogen test failures

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

Hi Ali,

It looks like you did a "make check" before "make install" and a couple
of tests failed.

+ cmp -s nested-res2.base nested-res2.out
+ diff nested-res2.base nested-res2.out
+ failure 4,10d3
< able     -- no value
< bar      -- integer:   1234
< foo      -- string:   foo	lish
< stumble  -- no value
<
< struct opt #2:
< struct   -- nested:   0xXXXXXXXX
FAIL: nested.test

+ diff cfg-edit.sample-cfg cfg-edit-tmpd/cfg-edit.cfg
+ failure improperly saved state:
2,7d1
<   <able/>
<   <bar type=integer>0x4D2</bar>
<   <foo>foo&#x09;lish</foo>
<   <stumble/>
< </struct>
< <struct type=nested>
FAIL: cfg-edit.test

Please let me know what kind of platform you were running on and
send me the contents of the /home/ali/Documents/autogen/autoopts/test/FAILURES
directory.

Both of the failing tests use hierarchically valued option arguments,
so I suspect the two failures have the same cause.

Thank you -Bruce

====================================================
2 of 22 tests failed
Please report to aut...@li...
====================================================

[Autogen-users] autogen-5.9.7pre1.tar.gz

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

A patched autogen is now ready.  No more -Werror, unless you ask for it:

http://autogen.sourceforge.net/data/autogen-5.9.7pre1.tar.gz
http://autogen.sourceforge.net/announce.html

Re: [Autogen-users] autogen fails on -Werror under cygwin

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

Bruce Korb wrote:
> Hi Brian,
> 
> Thank you for the explanation.  I'll quiet down that warning stuff for the
> shipped autogen.

I've fixed it so from now on you have to ask for it with ``export WERROR=yes''.
I've done this on the theory that a) it's easier and b) my "clients" are more
interested in getting their work done than in helping me make sure that the
code is as excruciatingly clean as possible.  :)

I'll be posting autogen-5.9.7pre1.tar.gz to http://autogen.sourceforge.net/data
shortly.

Thank you all.  Regards, Bruce

Re: [Autogen-users] autogen build fails under cygwin

[Brian D. <br...@de...>]

Bruce Korb wrote:

> Or apply a cast to all integer type arguments?  Holy moly, what a lot
> of pain just to print a number....

Yes, truly portable C sure is a headache at times.  Rather than casts I
think I would just make colCt an unsigned int and use %u.  Worst case,
on a target with 16 bit int you would be limited to 65535 columns of
indentation, but that scenario doesn't seem very likely.

For the record, the idea of changing uint32_t et al on Cygwin to use int
instead of long for their typedefs to more align things with Linux and
quash these sorts of warnings has been recently discussed on the mailing
list.  One of the counterarguments was that it does highlight these
portability issues that would go otherwise unnoticed.  Of course, in
this case while the warning is correct in the sense that there could
hypothetically exist a problem on a system where int is less than 32
bits, in reality this is not the case for Cygwin and so it's just noise.

Brian

Re: [Autogen-users] autogen build fails under cygwin

[Dave N. <Dav...@na...>]

Thanks Brian and Bruce for the info. Watch out with guile 1.8; I have a bit 
of difficulty figuring out exactly what cygwin setup did, but it *appears* 
that the 1.8 cygwin distribution omits guile-config, upon which autogen 
make relies.
Thanks again for the help,
Best Regards, Dave

At 01:28 PM 11/22/2008, Bruce Korb wrote:
>Hi Brian,
>
>Thank you for the explanation.  I'll quiet down that warning stuff for the
>shipped autogen.  I was wanting to make the code as excruciatingly
>clean as I could.
>
>On Sat, Nov 22, 2008 at 8:50 AM, Brian Dessent <br...@de...> wrote:
> > Dave Nadler wrote:
> >
> >> - decipher the build complaint below and suggest what I've screwed up, or
> >
> > The problem is that CFLAGS contains -Werror which turns any minor
> > warning into a fatal error that stops the build.
>
> > The only portable way
> > to use uint32_t with printf is by using the corresponding format
> > specifier define from inttypes.h, i.e.
> >
> >  fprintf( stderr, "Cannot malloc %"PRIu32" bytes\n", colCt + 1 );
> >
> > This of course has its own set of portability issues since inttypes.h
> > isn't available everywhere.  Perhaps a better option would be to use
> > size_t and %zu.
>
>Or apply a cast to all integer type arguments?  Holy moly, what a lot
>of pain just to print a number....
>
>Grumble, grumble.  Thank you.  :)
>
> > These is good example of why it's a bad idea to ship software with
> > -Werror enabled by default.  It might be helpful for the developer of
> > the package to have it enabled but it is certainly unhelpful to the end
> > user who is just trying to use the software.  For this reason it's
> > traditional to have a --{en,dis}able-werror configure option that allows
> > for the end-user to override the package, however it seems that autogen
> > does not share this philosophy but instead forces -Werror.  Ouch.
>
>Naw, the developer just didn't fully appreciate all the twisty little issues
>one might bump into.  Please note:  this isn't my day job.  One company
>did send me a copy of VM Ware as a token of appreciation.  But this
>doesn't put any food on my table.
>
> >  This
> > is a new development, so I'd say one workaround would be to simply use
> > an older version.  5.9.5 should be fine.  You could also edit
> > configure.in and regenerate configure.
>
>I'm out of town for the next week. I'll change the warning thing and
>repackage a 5.9.7 in early December.  If there are any more issues,
>please email 'em.  :)
>
> > The problem with getting autogen working with Cygwin lies in libguile.
> > The binary version provided by the distro was built with an incompatible
> > version of gcc and so autogen built against it segfaults at startup.
> > It's been reported multiple times but the guile maintainer is still in
> > denial that a problem exists.  So, you need to build guile yourself from
> > source.
>
>On UNIX platforms, that's been pretty easy, since they moved from 1.4 to 1.6.
>They're on 1.8 now.
>
>Again, thank you, Brian, for your feedback.  -Werror will be gone next
>time.  Sorry.
>
>Regards, Bruce

Dave Nadler, USA East Coast voice (978) 263-0097,  dr...@na... 

Re: [Autogen-users] autogen build fails under cygwin

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

Hi Brian,

Thank you for the explanation.  I'll quiet down that warning stuff for the
shipped autogen.  I was wanting to make the code as excruciatingly
clean as I could.

On Sat, Nov 22, 2008 at 8:50 AM, Brian Dessent <br...@de...> wrote:
> Dave Nadler wrote:
>
>> - decipher the build complaint below and suggest what I've screwed up, or
>
> The problem is that CFLAGS contains -Werror which turns any minor
> warning into a fatal error that stops the build.

> The only portable way
> to use uint32_t with printf is by using the corresponding format
> specifier define from inttypes.h, i.e.
>
>  fprintf( stderr, "Cannot malloc %"PRIu32" bytes\n", colCt + 1 );
>
> This of course has its own set of portability issues since inttypes.h
> isn't available everywhere.  Perhaps a better option would be to use
> size_t and %zu.

Or apply a cast to all integer type arguments?  Holy moly, what a lot
of pain just to print a number....

Grumble, grumble.  Thank you.  :)

> These is good example of why it's a bad idea to ship software with
> -Werror enabled by default.  It might be helpful for the developer of
> the package to have it enabled but it is certainly unhelpful to the end
> user who is just trying to use the software.  For this reason it's
> traditional to have a --{en,dis}able-werror configure option that allows
> for the end-user to override the package, however it seems that autogen
> does not share this philosophy but instead forces -Werror.  Ouch.

Naw, the developer just didn't fully appreciate all the twisty little issues
one might bump into.  Please note:  this isn't my day job.  One company
did send me a copy of VM Ware as a token of appreciation.  But this
doesn't put any food on my table.

>  This
> is a new development, so I'd say one workaround would be to simply use
> an older version.  5.9.5 should be fine.  You could also edit
> configure.in and regenerate configure.

I'm out of town for the next week. I'll change the warning thing and
repackage a 5.9.7 in early December.  If there are any more issues,
please email 'em.  :)

> The problem with getting autogen working with Cygwin lies in libguile.
> The binary version provided by the distro was built with an incompatible
> version of gcc and so autogen built against it segfaults at startup.
> It's been reported multiple times but the guile maintainer is still in
> denial that a problem exists.  So, you need to build guile yourself from
> source.

On UNIX platforms, that's been pretty easy, since they moved from 1.4 to 1.6.
They're on 1.8 now.

Again, thank you, Brian, for your feedback.  -Werror will be gone next
time.  Sorry.

Regards, Bruce