VS2015 default configuration appears wrong

[mikkelfj]

It appears that a MSVC build on AppVeyor does not work with the defualt configuration "debug|x86".
I could play around with config parameters, but a CMake build does not require any additional arguments.

Meson appveyor file and output
https://github.com/dvidelabs/flatcc/blob/meson/appveyor.yml
https://ci.appveyor.com/project/dvidelabs/flatcc/build/win%23528/job/hxiggovps87cpar4

similar CMake appveyor.yml file
https://github.com/dvidelabs/flatcc/blob/master/appveyor.yml

"c:\projects\flatcc\build\MSVC\flatcc.sln" (default target) (1) ->
       (ValidateSolutionConfiguration target) -> 
         c:\projects\flatcc\build\MSVC\flatcc.sln.metaproj : error MSB4126: The specified
 solution configuration "debug|x86" is invalid. Please specify a valid solution
 configuration using the Configuration and Platform properties
 (e.g. MSBuild.exe Solution.sln /p:Configuration=Debug /p:Platform="Any CPU")
 or leave those properties blank to use the default solution configuration. 
[c:\projects\flatcc\build\MSVC\flatcc.sln]

[santagada]

you set in the appveyor.yml x86 and x64 and debug and release, I don't know about meson but can't you check the .sln to see which configurations are actually set in the solution? if you post the sln file generated I can take a look. I'm guessing that meson by default maybe only creates configurations for the host (which might be x64).

[mikkelfj]

I don't have access to the AppVeyor sln file, but I have attached one generated on my Mac. Otherwise you can generate one from the repo using

mkdir -p build/MSVC; cd build/MSVC; meson ../.. --backend=vs2015 --buildtype=debug

flatcc.sln.zip

[mikkelfj]

It looks like your assumption is right. I don't see any x86 in the file.

[mikkelfj]

It seems that I don't have any if platform guards in the meson version of the AppVeyor file, but I do in CMake, so I will try make this change and report back.

[mikkelfj]

The thing is, in CMake you have -G "Visual Studio 14 2015" or -G "Visual Studio 14 2015 Win64"
with an optional Win64 at the end. I'm not sure what the equivalent would be in Meson, hence a plaform guard would make no difference.

[mikkelfj]

Removing the x86 arch starts the build - but I would like to know if it's possible to target both x86 and x64 without crosscompiling, and the same goes for travis/ninja backends - though for travis I have not set that up with CMake either.

As to the results of compiling without x86 I am now getting two errors both related to not finding flatcc.lib

(I disabled parallel:true in AppVeyor but it changed nothing)

https://ci.appveyor.com/project/dvidelabs/flatcc/build/win%23532/job/o4l8qu6xqwhen1lg

• line 297 LINK : fatal error LNK1104: cannot open file 'flatcc.lib' [c:\projects\flatcc\build\MSVC\[email protected]]

I build two libraries: libflatcc (larger lib) and libflatccrt (smaller runtime lib). The flatcc.exe app fails to link with libflatcc (the larger lib). I'm not sure about the runtime lib - since so much depends on flatcc.exe being built first.

For comparision, here is a successful AppVeyor CMake driven x64 debug build although it might not build all the tests due to CMake limitations.
https://ci.appveyor.com/project/dvidelabs/flatcc/build/win%23527/job/v05oor7eqaqp6uid

and here is a successful travis build of the meson branch:
https://travis-ci.org/dvidelabs/flatcc/jobs/259276505

[NickeZ]

I'm sure I'm way to late since this is about one year later. but the answer to your question is probably to load the correct environment variables from visual studio for x86 before running meson:

call "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" x86

See https://github.com/mesonbuild/meson/blob/master/.appveyor.yml#L101

[nirbheek]

@NickeZ is probably right, and yes, sorry about the late response :)

Closing this bug, please reopen if it's still an issue!

[mikkelfj]

That is the correct workaround - but it is painful compared to CMake that can do this automatically. However you can’t avoid vcvars anyway when testing multiple compiler versions.

I’ll leave this closed since you don’t seem to want to follow the CMake approach.

[nirbheek]

@mikkelfj you're looking for #2622.

[NickeZ]

Actually I think they are looking for #3382

[mikkelfj]

Good, looking forward to it. Note that compilers all the way back to MSVC 2010 is important for retro testing C projects.

[nirbheek]

Actually I think they are looking for #3382

That's actually fundamentally broken, because it will do compiler checks with the wrong compiler and hence is quite likely to generate bad build files unless the project is very simple

[NickeZ]

My bad, I thought CMake could generate any backend on any platform. Sorry for the noise.