Possible bug in g-wrap gw-* code

[Rob Browning]

Derek Atkins <warlord@MIT.EDU> writes:

> I've looked into this and there is no easy way to do this.  The
> version of automake we require (1.4 -- which is the default on RH7.3)
> only provides a per-directory AM_CFLAGS.  Newer versions of automake
> do enable per-library CFLAGS, but it still wont let us do this
> per-file.  Besides, this means you have to hack around the issue every
> time you use g-wrap, so it's not a "change once and fix everything"
> option like your next two...

The approach I had been thinking about shouldn't depend on the
automake version involved.  One option would be to just put a pattern
override rule for each g-wrap file in the relevant Makefile.am's.

  GW_CFLAGS := $(filter-out -Wno-uninitialized, $(CFLAGS) $(CPPFLAGS))

  gw-foo.c gw-foo.h: gw-foo-spec.scm
  gw-foo.o: gw-foo.c gw:foo.h
          $(CC) -c ${GW_CFLAGS}

Of course if you're not willing to presume GNU make, this won't work,
but there are plenty of other variations on this theme that could
probably be designed to work just fine.  Heck, if you wanted to run a
script or similar at the end of configure.in, and use make "includes"
then you could possibly even automate most of the process with or
without GNU make.

> Also, I am fairly confident that a cast of '0' to any type is
> sufficient for any scalar type in ANSI-C.  My reasoning is that the
> cast will sign-extend the 0, so it will do the right thing (provided
> you cast..  You can't do "<type> <name> = 0;" and have it necessarily
> work in all cases.

I'm also concerned about things like alignment on various archs,
though I agree that we can almost certainly come up with something,
even it it requires some #ifdefery that should work.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD