[Mesa-dev] Meson windows v5 (10/19/2018) review

[Jose Fonseca]

On 21/10/18 20:54, Liviu Prodea wrote:
> 1. When using Meson 0.48.x both -Dc_args -Dcpp_args and -Db_vscrt 
> methods of selecting the CRT are ineffective on changing the CRT from MD 
> to MT resulting in build failure if LLVM is built with MT CRT. This 
> issue persists from last time I tested this WIP branch. However if MT 
> built LLVM is indeed unsupported unlike Scons I am OK with it as long as 
> it is documented.

> 2. Assuming no 1 has been worked around (we have LLVM built with MD CRT 
> available), LLVM JIT-ed drivers like llvmpipe and swr cannot be selected 
> despite resulted opengl32.dll being around 20MB and swr DLLs being built 
> as well only when expected. Tested with GPU Caps Viewer (a 32-bit only 
> software), it reports the driver as softpipe OpenGL 3.1 with 248 
> extensions.  Since it's 32-bit app I did not attempt to build swr for 
> this test as it's unsupported for 32-bit apps.  It appears this is a 
> really persistent issue as I had it right from the first time I tested 
> this branch. Maybe I need to change the recipe I use to build LLVM so 
> that I use Meson instead of CMake. That would be really unpleasant if it 
> turns out to be the root of this problem. I have this marked as optional 
> and it is on least priority on my TODO list:
> 
> https://github.com/pal1000/mesa-dist-win/issues/7 
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpal1000%2Fmesa-dist-win%2Fissues%2F7&data=02%7C01%7Cjfonseca%40vmware.com%7C201e146521934e79895f08d63790411a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636757490087355401&sdata=KOompJzgdq2B9tawfDqGxxlXOLNqm0EbGRD9%2F9T%2FtHU%3D&reserved=0>
> 
> 3. More filename parity with Scons similar to
> 
> https://gitlab.freedesktop.org/dbaker/mesa/commit/f31d0802da6a20b3878a789bb38c9733c4b0ff24#bda6b0f93966e610f473867639a87adfc5437011 
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fdbaker%2Fmesa%2Fcommit%2Ff31d0802da6a20b3878a789bb38c9733c4b0ff24%23bda6b0f93966e610f473867639a87adfc5437011&data=02%7C01%7Cjfonseca%40vmware.com%7C201e146521934e79895f08d63790411a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636757490087355401&sdata=GbvqWeGNGKV1ylnh9X6ddXE2ExtxSSrX8i4nnpX9zyo%3D&reserved=0>
> 
> - swrAVX-0.dll should be swrAVX.dll
> 
> - swrAVX2-0.dll should be swrAVX2.dll
> 
> - libOsmesa.dll should be osmesa.dll
> 
> 4. opengl32.dll built with Meson depends on shared library z.dll. I have 
> absolutely no problem with this but Jose Fonseca may not like this 
> considering one of his replies from the Scons gles option conversations.


Yep, we really don't want opengl32.dll (or any Mesa based OpenGL ICD) to 
depend on any DLL whatsoever besides Windows standard DLLs (this 
excludes even MSVC runtime, hence the need of /MT /MTd.)  This is 
because these drivers will be loaded onto arbitrary process are normally 
installed into C:\Windows\system32, hence any dependencies will need to 
be installed there, so depending on a z.dll could clash with z.dll 
shipped by applications


Regarding MT vs MTd, I've often considered just always use /MT and side 
step the runtime mismatch issue completely, because I honestly don't 
remember the debug C runtime ever helping debugging anything.  In fact, 
we often use cross compiled MinGW binaries for day-to-day development 
anyway.


Jose