[Geany-Devel] Plugins Quality Check

[Colomban Wendling]

Le 21/02/2014 03:16, Lex Trotman a écrit :
> [...]
> 
> Well, the same as for code written by humans, the C compiler warning
> is telling us something *might* be wrong with the code.  The Vala
> compiler may have bugs, so such things need checking the same as
> manual code, to avoid possible UB.  If, as in these cases, it seems to
> be ok, then its just noise, but unless you check you don't know.
> 
>> IMO, we should just disable warnings on Vala's generated code altogether and
>> rely only on the Vala warnings. Anything else is a Vala bug and not our
>> problem. I would've done this long ago but I'm not sure how to
>> properly/portably disable warnings for a particular target in Autotools.
> 
> Whilst I don't agree totally (see above), thats probably better, but I
> dunno how to do it either, Autotools experts please assist.

Per-target flags are easy, they are target_CFLAGS, target_LDFLAGS and so
on.  Thought, note this is per *target*, so if you mix C and Vala in the
same target, obviously those flags will apply to all use of the C
compiler, linker, etc. for this target.

To disable warnings, there are 2 solutions:

1) don't add the warning flags;
2) add flags to disable the warnings.

Solution 1) seems reasonable, but it won't be able to remove user-set
warnings in CFLAGS -- and we just *cannot* ignore user CFLAGS, there may
be include paths and stuff.

Also, with the current setup it seems easier to just add flags than
remove existing ones, because currently they are added automatically in
vars.build.mk.  Adding them conditionally may be tricky, because AFAIK
make conditionals are unportable (e.g. BSD make and GNU make aren't
compatible).  Maybe Loong Jin knows better?

Even if we go with solution 2), we have 2 ways to apply it:  overriding
some user warnings flags or not.  Overriding user warning flags would
allow for users to have stricter warnings for real C code while not
being flooded by Vela-generated ones, but again, it may be considered
harmful.  OTOH, if we don't override it basically only benefit people
not having a custom CFLAGS defined (even if it is set to the same value
as our default).

Attached are 2 examples of solution 2), not overriding and overriding.
Just toy patches for now, but it should work.

> 
> [...]
>>
>> The GTK2 Vala binding is deprecated, same as the GTK2 C API/library. There
>> is a compiler flag for Valac to make it disable the deprecation warnings, if
>> that is desirable.

Is there really a flag to only disable deprecated warnings?  IIRC there
is only --disable-warnings, and IIUC it removes everything not an error?

Cheers,
Colomban
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gp-vala-cflags-2.diff
Type: text/x-diff
Size: 2087 bytes
Desc: not available
URL: <http://lists.geany.org/pipermail/devel/attachments/20140221/8acad6df/attachment.diff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gp-vala-cflags.diff
Type: text/x-diff
Size: 1696 bytes
Desc: not available
URL: <http://lists.geany.org/pipermail/devel/attachments/20140221/8acad6df/attachment-0001.diff>