Re: Official .defs files

[Rob Browning <rlb cs utexas edu>]

Karl Nelson <kenelson flounder ece ucdavis edu> writes:

> Do you agree the above example is bad practice? 

For a public API that's going to be widely distributed, yes, I'd
generally agree, but that doesn't matter wrt my original point which
was something more like:

  enum {
  #ifdef ARCH1
    FOO = SOMETHING,
  #else
    FOO = SOMETHING_ELSE
  };

Here, I might want the .defs file to just list FOO, and let the right
value be chosen at compile/run time.  Again, while I agree that in
general this may be bad practice for a widely distributed public API,
and likely something you might even want to proscribe in GNOME/GTK
APIs, such a construct might be just fine for internal use in an app
that wants to use the .defs infrastructure to wrap its internal API so
that, for example, it's guile code can access its C functions.

> I would say for what I am concerned with (and the point of the GNOME
> language bindings list), the defs format are intended for wrapping
> GLIB/GTK/GNOME and other APIs which are reasonable conforming to
> them. 

OK.  Then if this is correct, then my points may be moot.  I was just
under the impression that when the mailing list name was changed to
"language-bindings" it was intended to be targetted more generally.

> If you want to make defs more than GLIB using libs than please 
> go ahead.   Though if that cuts out of its primary mission of wrapping
> GTK/GNOME, that would be a very bad thing.

I don't think I've been discussing anything that would preclude
wrapping GNOME...

Anyway, I think I've made my point clear enough.  I think people at
least understand what I was concerned about, so I'll quit making noise
now :>

-- 
Rob Browning <rlb cs utexas edu> PGP=E80E0D04F521A094 532B97F5D64E3930