[gnutls-dev] Starting Guile integration
simon at josefsson.org
Fri Jun 1 15:30:34 CEST 2007
ludovic.courtes at laas.fr (Ludovic Courtès) writes:
> Just a quick reply before I actually look into the details (either later
> today or next week).
> Simon Josefsson <simon at josefsson.org> writes:
>> In the future, do you want to develop things in your git repository, and
>> ask me to pull things in when ready? I think that would work well, if I
>> can figure out which command I should be using for reviewing the changes
>> before committing them.
> Yes, that's how we could do. Alternatively, I could use
> `git-format-patch' and send the resulting messages to the list but as I
> said, that may introduce some undesirable overhead.
> My understanding is that `git-fetch' allows remote changes to be fetched
> locally without being actually integrated (and committed) locally.
> Then, it should be possible to find the latest remote commit ID in
> `.git/refs/remotes' and use that with `git-diff'. And finally, one
> should be able to `git-merge' to actually merge the changes locally.
> This is a bit vague, and that's because I haven't actually tried it. ;-)
> I'll report back when I have better experience.
Once you have something in your public repository that I should merge,
I'll try it.
>>> * Code in `guile/src' doesn't want to be compiled with
>>> `-Wstrict-prototypes'. Since adding `-Wno-strict-prototypes'
>>> doesn't annul the effect of `-Wstrict-prototypes', I'm afraid we'll
>>> have to remove `-Wstrict-prototypes' at the project level (i.e, in
>>> `configure.in'), and add it to `CFLAGS' in sub-directories where it
>>> makes sense.
>> Ouch. What is the reason the code needs this? Maybe we can fix that
>> problem instead. It seems to build for me now, though, with warnings,
>> but I'd rather have warning messages than potentially hiding other
> That's because Guile contains this declaration:
> SCM scm_c_define_subr (const char *name, long type, SCM (*fcn)());
> This function allows C code to bind C function FCN to the Scheme level
> under NAME. It makes perfect sense to have FCN declared this way,
> because FCN can have any number of arguments (its number of required,
> optional and "rest" arguments are specified as part of TYPE).
> I can't think of a better way to declare FCN. Requiring users to cast
> their functions to, e.g., `SCM (* fcn) (void)', is not an option. At
> any rate, should a fix be found for Guile, it won't be available until
> the next Guile release.
I can't think of a better solution right now. Still, do the warnings
cause any real harm? I'd rather not drop -Wstrict-prototypes if the
advantage of doing so would be to just hide some warnings. Did you try
changing the order of -Wno-strict-prototypes to see if you really can't
negate the effect of the other parameter?
> I'll take care of the other issues you mentioned later on.
More information about the Gnutls-devel