[Geany-Devel] Plugins Quality Check

[Matthew Brush]

On 14-02-21 06:30 AM, Colomban Wendling wrote:
> 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.
>

OK, I didn't think it was OK to assume GCC was the compiler, so I wasn't 
sure how you'd portably (across compilers) tell the compiler flags 
without doing a bunch of configure checks to see whether the compiler 
accepted such flags or something. My GCC/Clang-specific idea was to 
maybe just use something like `-Xcc=-w` or whatever in one of the 
VALAFLAGS variables to disable all warnings related to Vala code, though 
I'm not sure if Autotools invokes the C compiler via Valac or independently.

>>
>> [...]
>>>
>>> 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?
>

I believe Valac's --disable-deprecated option will disable it warning 
about deprecated annotations in the VAPI files. I'd have to test it to 
be sure though.

Cheers,
Matthew Brush