[vlc-devel] [PATCH 0/6] Fix warnings related to unknown attributes by introducing VLC_ATTR

[Filip Roséen]

Hi Jean-Baptiste,

On 2017-02-27 03:52, Jean-Baptiste Kempf wrote:

> On Sun, 26 Feb 2017, at 23:32, Filip Roséen wrote:
> 
> > Use the information available from *configure* *if* available (i.e.
> > when we are building VLC), otherwise fall back to a more easily
> > maintainable list of macros where we do not care about the exact
> > compiler being used. Instead we would maintain in a way that
> > corresponds to the current implementation. #ifdef __GNUC__ would
> > unconditionally define the macros to what the *“compiler of our
> > dream”* would implement.
> 
> 
> If I remember correctly, the issue with that, beside vlc_fixups, that is
> done for this, it is not a great idea to have headers that depend on
> output of configure and of config.h. (notably for out-of-tree module
> building compilation, but there were other cases).

For *out-of-tree* compilation it would still work as this approach no
longer has a mandatory dependency on the *configure* result, but an
optional one; or are you saying that even with the approach taken in
the [linked branch][1], with the [relevant commit][2] we will suffer?

[1]: https://github.com/FilipRoseen-refp/vlc/commits/0000_attributes
[2]: https://github.com/FilipRoseen-refp/vlc/commit/68ad551238b0b70de1c48bd977ac37dfe5de5f28

> I am quite sure this still exists in vlc_codecs.h, (the very badly named
> header), where we must have PACKED, but that should be the only other
> one where this exists.
> 
> 
> I remember that we had this discussion too, because we use the non-
> standard #warning and #error.

I was sadly not part of said discussion. If it is possible, could you
link me to the *mailing-thread/threads* so that I can read what was
stated there?

> But I totally agree on the fact that ifderies depending on compiler
> names and versions are really not cool too.
> Especially since we have way too many GCC-isms and GNU-isms.
> 
> And this is totally relevant since GCC is soon going to be our compiler
> only for most distributions of Linux. All the other ones will be using
> llvm/clang: indeed, even the Mingw migration to llvm is ongoing.

Best Regards,\
Filip Roséen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20170227/7c066aec/attachment.html>