[Mesa-dev] Meson mesademos (Was: [RFC libdrm 0/2] Replace the build system with meson)

[Jose Fonseca]

On 25/03/17 01:25, Dylan Baker wrote:
> Quoting Jose Fonseca (2017-03-24 14:16:13)
>>
>> Evaluating is one thing.  Actually migrating is another.
>>
>> Brian already said he'd take a look and evaluate.  And I'll help in what
>> I can.  I agree we should all evaluate early.
>>
>>
>> But I don't think that the proposal of first migrate scons to meson,
>> then in a second separate step migrate autotools to meson, is viable.
>> Like I said: there's no knowledge overlap.  The two group of people --
>> the Meson and Windows experts -- will be chasing each other tails.  And
>> all that while, the build will continue to be broken or diverge because
>> master dev will go on.
>>
>>
>> Jose
>
> https://github.com/dcbaker/mesa-demos wip/meson
>
> I've blindly ported some of the windows bits but have no way to test them, so
> you can either delete the lot and go from scratch or see what's left to fix (the
> wgl folder, for example). I have not implemented much of the windows or apple
> logic in the root CMakeLists.txt, so hopefully that's useful for your purposes.
>
> That branch also builds on my Archlinux machine, but not on debian due to
> difference in the way they package freeglut I just ran out of time today. For
> the record, I started at about 12:00, and finished at about 17:00 with a 1 hour
> lunch in there. So about 3 hours to get a mostly working build. I'm going to try
> to iron out the debian and travis issues either over the weekend or next week.
>
> There is one difference, because ninja is non-recursive some targets would have
> the same name and collide, so I've renamed some of the not installed binaries. I
> believe that a non-recursive make (such as one generated by cmake) would have
> the same problem. meson doesn't seem to have a method to rename the target, but
> it's also a bit of an odd corner to build multiple binaries with the same name
> that are both not installed and are for people (not automated build steps) to
> use.
>
> I also have a not quite working .travis.yml on that branch.
>
> I'm also planning to get a mesa RFC sent out early next week once I get i965 and
> llvmpipe building.
>
> If we merge mesa we (Intel) will move to using meson as our primary build system
> in CI (the one we run tests against) as soon as it's ready. Building mesa is
> quite slow for us considering the power of our build hardware, and meson should
> help with that. We'll continue to build autotools much the way we do scons now,
> as a secondary "buildtest" only target.
>
> Dylan

Thanks Dylan.  I checkout your branch.

Let's forget about MSVC for now.  Let's focues on MinGW which tends to 
be both more complex (due to cross compilation), and should be dead easy 
for any Linux developer to build for.


I've pushed the branch to mesa/demos, so we can all collaborate without 
wasting time crossporting patches between private branches.

   https://cgit.freedesktop.org/mesa/demos/commit/?h=meson

Unfortunately, I couldn't actually go very far until I hit a wall, as 
you can see in the last commit message.


The issue is that Windows has no standard paths for dependencies 
includes/libraries (like /usr/include or /usr/lib), nor standard tool 
for dependencies (no pkgconfig).  But it seems that Meson presumes any 
unknown dependency can be resolved with pkgconfig.


The question is: how do I tell Meson where the GLEW headers/library for 
MinGW are supposed to be found?


I know one solution might be Meson Wraps.  Is that the only way?


CMake makes it very easy to do it (via Cache files as explained in my 
commit message.)  Is there a way to achieve the same, perhaps via 
cross_file properties or something like that?


Jose