Bruce Korb wrote:
> So, please send me a config test to be able to differentiate the
> first-born "funopen" from the one of CygWin heritage. I'll add an
> "is there a libio.h header?" guard around the #include.
Have a look at the attached. I haven't actually been able to test this
patch past the point at which I've verified that the configure tests
work and seem to set the correct #define, because I have come to the
conclusion that it's impossible to actually bootstrap autogen unless
you're Bruce Korb.
Allow me to digress for a moment and share the incredibly frustrating
experience that I have had trying to contribute this seemingly simple
patch. Here are roughly the steps that I followed, which resulted in
many many hours of head scratching for what should have been a
relatively routine change.
I looked in autogen-5.9.4/config, saw that ag_macros.m4 is generated
from misc.def. So I edited misc.def adding the initial version of a
configure test in the patch, as well as editing
autogen-5.9.4/agen/fmemopen.c. I rebuilt with "make", and nothing had
really changed. I scoured the Makefiles and determined that there were
absoltely no rules to regenerate ag_macros.m4 in a release tarball
whatsoever, which meant no way to actually test changes to misc.def.
So I checked out a CVS tree and ported over the patches I was working on
from the 5.9.4 release tree. I ran the bootstrap script and things
started going. After a while it stopped with an error about a missing
'allbut' command. I then spent a couple of hours scouring google
results, the Debian package database, and mailing list archives. I
found absolutely nothing except a lot of irrelevant hits. Looking at
the bootstrap.dir file I could infer what 'allbut' was supposed to do so
I wrote a replacement in perl.
I again started the bootstrap and it again failed due to lack of some
command called mk-fwd. Again I spent a lot of time googling, grepping
codebases, searching for filenames in Debian packages. I came up with
nada, other than the knowledge that it's a script to automatically
generate forward static declarations. So having wasted all this time I
make it a symlink to /bin/true and continued.
And yet again I got a failure for a missing command called char-mapper.
Again, it was off to google, mailing list archives, anything. But again
more time wasted as this is yet another apparently private tool that
nobody has. I can't even begin to deduce what this tool is supposed to
do. So I symlink it to /bin/true and continue.
And of course, that's not it. Yet another failure due to lacking
something called mk-str2enum. More googling, more hair loss. Having no
idea how anyone actually ever contributes anything to autogen I again
symlink it to /bin/true and restart the bootstrap script.
This time it finishes, so that I can for the first time -- many hours
later -- actually run configure and see if the test I wrote does
anything. Surprise, it's busted. So I tweak it, re-run bootstrap,
repeat this a few times until I have something that seems to be correct.
I then want to build the code to see if the fmemopen.c changes work, but
surprise! No such joy! Because I was missing all those random mystery
tools, the bootstrap didn't actually succeed and I can't build anything
because there are apparently files that were supposed to get edited that
didn't. fmemopen.c for example expands to nothing because the first
statement in it is "#if defined(ENABLE_FMEMOPEN)" yet there's no
#include "config.h". So even if I try to force it to compile with "make
agen5/fmemopen.o", I get a completely empty object despite
ENABLE_FMEMOPEN being defined in config.h. I presume this is because
some of those missing tools were necessary to add an #include
"config.h", but I don't know.
I am totally stuck now. If I try to build autogen I get:
make[3]: Entering directory `/build/autogen/autoopts'
make[3]: *** No rule to make target `xat-attribute.h', needed by
`libopts.c'. Stop.
I can't just rebuild in a release tree because it has no rules to
regenerate ag_macros.m4. I can't build anything in the CVS tree because
I don't have these tools that seemingly don't publicly exist. I'm
hosed, and I've wasted an enormous amount of time futzing around, all
because I wanted to be a good GNU citizen and help contribute patches
but instead I've got something that I can at best test halfway -- which
is doubly sad given that I'm rather sure the maintainer doesn't have a
newlib or Cygwin system to test on either.
Can you *PLEASE* document in CVS somewhere what these commands allbut,
mk-fwd, mk-str2enum, and char-mapper are and if they are not publicly
available, state that it's not possible to bootstrap from CVS at all?
It would really have saved me a lot of time and hair loss.
Thank you, and I'm very sorry if I come off as overly grouchy.
Brian
2008-03-11 Brian Dessent <[EMAIL PROTECTED]>
* config/misc.def (do_always): Check for funopen cookie typedefs
and define FUNOPEN_FLAVOR to 'bsd' or 'newlib'.
* agen5/fmemopen.c: Don't define typedefs for cookie_*_function_t
types for newlib systems.
agen5/fmemopen.c | 3 ++-
config/misc.def | 31 +++++++++++++++++++++++++++++++
2 files changed, 33 insertions(+), 1 deletion(-)
Index: config/misc.def
===================================================================
RCS file: /sources/autogen/autogen/config/misc.def,v
retrieving revision 4.22
diff -u -p -r4.22 misc.def
--- config/misc.def 2 Dec 2007 22:42:00 -0000 4.22
+++ config/misc.def 12 Mar 2008 06:54:10 -0000
@@ -442,6 +442,37 @@ do-always = <<- _END_ALWAYS_
;;
esac
AC_C_INLINE
+
+ # Note that BSD does not typedef these in its headers, but instead
+ # calls for them to be identical in signature to read(2), write(2),
+ # lseek(2), and close(2). Newlib however does include typedefs
+ # in its stdio.h for these, and they do not match the signatures
+ # of the BSD implementation. So this test relies on the fact
+ # that any typedef will succeed for BSD, while only one that
+ # matches the existing definitions in stdio.h will succeed for
+ # a newlib system.
+
+ if test "X${ac_cv_func_funopen}" = Xyes; then
+ AC_CACHE_CHECK([for cookie_function_t type],
+ [ag_cv_cookie_function_t],
+ [AC_TRY_COMPILE([#include <stdio.h>
+ typedef int cookie_read_function_t (void *, char *, int);
+ typedef int cookie_write_function_t(void *, char const *,
int);
+ typedef fpos_t cookie_seek_function_t (void *, fpos_t, int);
+ typedef int cookie_close_function_t(void *);
+ ], [], ag_cv_cookie_function_t="bsd",
+ AC_TRY_COMPILE([#include <stdio.h>
+ typedef ssize_t cookie_read_function_t (void *, char *,
size_t);
+ typedef ssize_t cookie_write_function_t(void *, const char *,
size_t);
+ typedef int cookie_seek_function_t (void *, _off64_t *,
int);
+ typedef int cookie_close_function_t(void *);
+ ], [], ag_cv_cookie_function_t="newlib",
+ AC_MSG_ERROR([Unknown flavor of cookie_foo_t types])))])
+ fi
+ if test "X${ag_cv_cookie_function_t}" = Xbsd; then
+ AC_DEFINE([NEED_COOKIE_FUNCTION_TYPEDEFS], [1],
+ [Define if typedefs for the funopen function pointers are
required.])
+ fi
AC_CACHE_CHECK([for static inline], [snv_cv_static_inline], [
AC_TRY_COMPILE([static inline foo(bar) int bar; { return bar; }],
[return foo(0);],
Index: agen5/fmemopen.c
===================================================================
RCS file: /sources/autogen/autogen/agen5/fmemopen.c,v
retrieving revision 4.16
diff -u -p -r4.16 fmemopen.c
--- agen5/fmemopen.c 23 Jan 2008 00:36:01 -0000 4.16
+++ agen5/fmemopen.c 12 Mar 2008 06:54:10 -0000
@@ -74,11 +74,12 @@
typedef size_t fmem_off_t;
typedef fpos_t seek_pos_t;
+# ifdef NEED_COOKIE_FUNCTION_TYPEDEFS
typedef int (cookie_read_function_t )(void *, char *, int);
typedef int (cookie_write_function_t)(void *, char const *, int);
typedef fpos_t (cookie_seek_function_t )(void *, fpos_t, int);
typedef int (cookie_close_function_t)(void *);
-
+# endif
#else
# error OOPS
Choke Me.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Autogen-users mailing list
Autogen-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/autogen-users
