[Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Emil Velikov]

On 21 March 2017 at 05:00, Jonathan Gray <jsg at jsg.id.au> wrote:
> On Tue, Mar 21, 2017 at 08:28:22AM +1100, Timothy Arceri wrote:
>>
>>
>> On 21/03/17 06:39, Emil Velikov wrote:
>> > On 20 March 2017 at 18:30, Matt Turner <mattst88 at gmail.com> wrote:
>> > > On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> > > > Seems like we ended up all over the place, so let me try afresh.
>> > > >
>> > > > Above all:
>> > > >  - Saying "I don't care" about your users is arrogant - let us _not_
>> > > > do that, please ?
>> > >
>> > > Let's be honest, the OpenBSD is subjecting itself to some pretty
>> > > arbitrary restrictions caused including Mesa in its core: 10+ year old
>> > > GCC,
>> > IIRC Brian was using old MinGW GCC, which was one of the blockers - it
>> > wasn't OpenBSD to blame here ;-)
>>
>> Sorry Emil I probably wasn't clear in our discussion. I sent out patches to
>> switch to GCC 4.8 last Sept (I believe this was needed by RHEL6) [1].
>>
>> Brain jumped in and said "I'm still using the MinGW gcc 4.6 compiler. I'd
>> rather not go through the upgrade hassle if I don't have to."
>>
>> Followed by Jose "We're internally building and shipping Mesa compiled with
>> GCC 4.4 (more specifically 4.4.3).
>>
>> It's fine if you require GCC 4.8 on automake, but please leave support
>> for GCC 4.4.x in SCons."
>>
>> By this point I got bored and moved on. But OpenBSDs GCC is a fork with
>> various features backported, from what I understand Mesa would not build on
>> a real GCC 4.2 release and we should not be using it as a min version. IMO
>> if OpenBSD want to maintain a GCC fork they can handle a patch to downgrade
>> the min GCC version.
>>
>> I believe Jonathan would like us to stick with 4.2 as min but is prepared to
>> deal with it if we move on.
>
> I would like to see Mesa test features it uses in configure rather than
> arbitary versions that are what a certain linux distribution ships with.
> The zlib change for instance didn't reference any specific problems with
> older versions or interfaces required from newer versions.
>
> We have one platform using clang/lld now (arm64) and are likely to move
> others in future where possible.  libtool has to be patched and the Mesa
> configure script regenerated to make this work or Mesa won't build due
> to libtool.m4 looking for specific strings in ld -v produced by bfd
> binutils or gold...
>
> And yes if you change the configure script to check for a newer version
> I'll revert it locally like I did with the zlib one.
>
> As I get the impression no one cares about patches for older GCC I've
> not being sending them to the list, ie
>
> commit d3d340d6026e516cc405a2eb1d925a7a7a467480
> Author: Jonathan Gray <jsg at jsg.id.au>
> Date:   Thu Mar 16 00:30:07 2017 +1100
>
>     i965: don't use designated array initialisation
>
>     Don't use a form of designated array initialisation that breaks gcc 4.2.1.
>
Jonathan, I think you meant to say:
Using C99 designated initializers is not allowed in C++ code, thus the
compiler may warn or even fail.

>
>     Signed-off-by: Jonathan Gray <jsg at jsg.id.au>
>
> diff --git a/src/intel/compiler/brw_vec4_gs_visitor.cpp b/src/intel/compiler/brw_vec4_gs_visitor.cpp
> index 4a8b5be30e..e7a502306e 100644
> --- a/src/intel/compiler/brw_vec4_gs_visitor.cpp
> +++ b/src/intel/compiler/brw_vec4_gs_visitor.cpp
> @@ -585,23 +585,6 @@ vec4_gs_visitor::gs_end_primitive()
>     emit(OR(dst_reg(this->control_data_bits), this->control_data_bits, mask));
>  }
>
> -static const GLuint gl_prim_to_hw_prim[GL_TRIANGLE_STRIP_ADJACENCY+1] = {
We already have C helper get_hw_prim_for_gl_prim that we can use instead.
I'll send a patch in a minute.

Thanks
Emil