Skip to content

Conversation

@sylveon
Copy link
Contributor

@sylveon sylveon commented Oct 1, 2022

Also, enable fast path for Clang and give friendlier errors to MSVC.

Testing the __has_declspec_attribute path revealed to be a bit tricky, because a bunch of CRT headers rely on MS extensions. I ended up passing -fno-declspec to disable __declspec specifically and then adding #define __declspec(x) to no-op all the __declspec in the CRT headers and cppwinrt. This finally gave the desired error:

_build\x64\Debug\winrt/base.h(688,9): error: static_assert failed due to requirement 'std::is_void_v<IClassFactory>' "To use classic COM interfaces, you must compile with -fms-extensions."
        static_assert(std::is_void_v<T> /* dependent_false */, "To use classic COM interfaces, you must compile with -fms-extensions.");
        ^             ~~~~~~~~~~~~~~~~~

Also, enable fast path for Clang and give friendlier errors to MSVC
@kennykerr
Copy link
Collaborator

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@kennykerr
Copy link
Collaborator

Looks the build is completely broken again... @DefaultRyan

@sylveon
Copy link
Contributor Author

sylveon commented Oct 3, 2022

Looks like NuGet stuff is failing, I don't imagine my PR is the source of these issues.

@DefaultRyan
Copy link
Member

Looks like this: microsoft/azure-pipelines-tasks#16088 issue here. Investigating how to workaround.

@DefaultRyan
Copy link
Member

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@DefaultRyan
Copy link
Member

I think I may have figure out a fix. Our build pipeline actually had an explicit "Use NuGet version x" step, but it was only being used on manual builds for some reason. I took out the conditional to have it run always, and upped the NuGet version from 5.3 to 6.0.2 while I was at it, and got a successful pipeline run internally. I just kicked off a run here, so let's see if that goes well.

@DefaultRyan
Copy link
Member

PS: Moving our pipeline over to be YML-based would probably help in that we'd have more visibility and transparency with what's actually happening in the pipeline. But as with everything, that conversion would take time, and I'm not sure if the value provided would be worth the effort. Anybody have any thoughts? Is there a big clamoring for this to happen that I'm unaware of?

@dmachaj
Copy link
Contributor

dmachaj commented Oct 4, 2022

I recently changed the build agents to a newer Windows version so that they would have VS2022 installed. I had only worked with YML build definitions before that (not with the classic UI). I found it a bit confusing and think it would have been easier to make that change if the Windows version was in YML for each phase of the build. (The version needed updating for like 3 or 4 levels of job and I kept missing some).

@kennykerr kennykerr requested review from DefaultRyan and oldnewthing and removed request for DefaultRyan October 5, 2022 15:21
@kennykerr
Copy link
Collaborator

Wish we had negative unit tests - this is impossible for me to "code review". 😭

@kennykerr
Copy link
Collaborator

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@kennykerr kennykerr merged commit 61b054a into microsoft:master Oct 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants