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

[Liviu Prodea]

 --default_library=static indeed solves the zlib and expat dependency so I tweaked my build script to do just that, As for the LLVM linking problems I think I finally understand what's going on. llvm-wrap option always links LLVM dynamically and ignores or it is incompatible with -Dshared-llvm=false. llvm-wrap could be coerced into supporting CRT override in Meson <= 0.47.2 using c_args and cpp_args but Meson >= 0.48.0 doesn't override it anymore, maybe this was unsupported to begin with. It's too bad that Appveyor VS toolchain update in
https://gitlab.freedesktop.org/dbaker/mesa/commit/6a39ee654abbb7c6de79ca138c5ac65108afe864
failed so bad leading a premature build failure otherwise the CRT mismatch error I see when LLVM is built with MT would have been replicated by Appveyor with a small difference, it would be a MD<->MTd mismatch instead of a MD<->MT.
I think fixing Appveyor failure from here 

https://ci.appveyor.com/project/dcbaker/mesa/builds/19646797/job/9maasfn20gh4ktcb
is as simple as
diff --git a/appveyor.yml b/appveyor.yml
index c807905..84d48a7 100644
--- a/appveyor.yml
+++ b/appveyor.yml
@@ -68,7 +68,7 @@ install:
 - if "%BUILD_SYSTEM%"=="meson" set Path=C:\Python37-x64\Scripts;%Path%
 - if "%BUILD_SYSTEM%"=="meson" meson --version
 - if "%BUILD_SYSTEM%"=="meson" cinst -y pkgconfiglite
-- if "%BUILD_SYSTEM%"=="meson" call "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" x86
+- if "%BUILD_SYSTEM%"=="meson" call "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvarsall.bat" x86
 # Install flex/bison
 - set WINFLEXBISON_ARCHIVE=win_flex_bison-%WINFLEXBISON_VERSION%.zip
 - if not exist "%WINFLEXBISON_ARCHIVE%" appveyor DownloadFile "https://github.com/lexxmark/winflexbison/releases/download/v%WINFLEXBISON_VERSION%/%WINFLEXBISON_ARCHIVE%"


    On Monday, October 29, 2018, 9:06:08 PM GMT+2, Dylan Baker <dylan at pnwbakers.com> wrote:  
 
 Quoting Jose Fonseca (2018-10-25 04:02:42)
> 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>

As an aside, I noticed that there was a bug in the llvm dependency handler on
windows that was stripping the \\ out of paths, that's been fixed in master now.

> > 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

To fix the z.dll (and expat.dll), set --default-library=static, this will make
any `library` calls into `static_library` instead of `shared_library`. Mesa
itself doesn't use `library`, we always set `static_library` and
`shared_library` explicitly.

Dylan

> 
> 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  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20181031/9707700b/attachment-0001.html>