On Fri, 27 Oct 2017, Daniel Stenberg wrote:

> On Fri, 27 Oct 2017, Martin Storsjö wrote:
>
>> I guess it'd be safe to at least amend it with an "||
>> defined(WINAPI_FAMILY)". I can send a PR with that.
>
> Thanks. Unfortunately that wasn't enough to please the appveyor ARM build. It
> fails the same way still:
>
> https://ci.appveyor.com/project/curlorg/curl/build/7.50.0.6028/job/5qdv9on98vy5wblc
>
> This is the state of the branch that ran the build:
>
> https://github.com/curl/curl/commits/bagder/appveyor-win32
>
> The win32 build now works so the ARM one now turned less interesting for me.
> Even if it would be useful to have that running too...

So, after looking closer at this... One vital clue is /D
_ARM_WINAPI_PARTITION_DESKTOP_SDK_AVAILABLE=1 in the compile command line.

Normally, you're not allowed to build for the desktop API subset when
building for ARM (i.e. you have to set WINAPI_FAMILY to some non-desktop
family) - unless this define is set, overriding this. (Binaries built like
this obviously can't be uploaded to the windows store.)

Now cmake actually doesn't set this anywhere in the generated vcxproj
files; it seems like it produces some odd cornercase of a vcxproj file
that actually isn't an UWP project or something similar, but a normal
desktop-style project, while still targeting ARM. When I try to create a
similar project file by clicking around in the Visual Studio IDE, I don't
get the same define set though. (No I haven't tried to diff the VS
generated vcxproj file to the cmake produced one to see what triggers
this.)

So we're actually not building something that tries to be a windows store
app, except that the linking stage (not sure if this is cmake's doing or
msbuild) doesn't link to all the necessary libs.

If I just add -DCURL_LIBS=advapi32.lib, building succeeds - but it doesn't
really test anything interesting; it tries to build a pretty much
unsupported/unintended thing, the same as normal desktop but for a
different arch.

To actually build it as a UWP project, add
-DCMAKE_SYSTEM_NAME=WindowsStore -DCMAKE_SYSTEM_VERSION=10.0. I
additionally have to add -DUSE_WIN32_LDAP=OFF since this doesn't seem to
be detected properly (the function it looks for is found, but the headers
don't contain everything that's needed to build the real deal).

And then further, I have to add -DCURL_DISABLE_TELNET=ON since this part
seems to use functions that aren't available in UWP (GetStdHandle,
PeekNamedPipe and some other ones).

With these cmake options, I manage to build libcurl, but the frontend tool
still has got a number of issues (SearchPathA, getch, CreateFileA,
GetEnvironmentVariableA, ExpandEnvironmentStringsA missing). For UWP,
libcurl probably is the only thing that really is relevant.

// Martin

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2017-10-29