Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build a TerminalAppLib and TerminalAppDll separately #2002

Conversation

zadjii-msft
Copy link
Member

This is a PR into #1948. I couldn't verify that the fix worked on just master, so I branched from the tip of 1948. I'll merge this into that PR, then finish that PR (it's all signed off, just blocked on this fix). If y'all want me to make a new version of the PR on master, I can do that.

Summary of the Pull Request

This is like a de-refactor of #1164. We're now building TerminalApp twice.
Once as a lib, and once as a dll. For whatever godforsaken reason, the wapproj
project type is a dumpster fire. If we try to build a static lib, then link
that into a DLL, the wapproj will absolutely not get all the resources,
dlls, xbfs, etc., that we need into the msix.

So now we're building TerminalApp twice. Once as a lib, which we'll use for
the unittests. Then we'll build it again, for consumption in WindowsTerminal.
All the combined files for these two projects are in
terminal-app-common.vcxproj, similar to host-common from the host project.

This does mean we'll have two pch.h steps for the same code. That's a giant
pain, but I think @miniksa is working on that.

References

PR Checklist

  This is like a de-refactor of #1164. We're now building TerminalApp _twice_.
  Once as a lib, and once as a dll. For whatever godforsaken reason, the wapproj
  project type is a dumpster fire. If we try to build a static lib, then link
  that into a DLL, the wapproj will absolutely _not_ get all the resources,
  dlls, xbfs, etc., that we need into the msix.

  So now we're building TerminalApp twice. Once as a lib, which we'll use for
  the unittests. Then we'll build it again, for consumption in WindowsTerminal.
  All the combined files for these two projects are in
  terminal-app-common.vcxproj, similar to host-common from the host project.

  This does mean we'll have two pch.h steps for the same code. That's a giant
  pain, but I think @miniksa is working on that.
@miniksa
Copy link
Member

miniksa commented Jul 17, 2019

This does mean we'll have two pch.h steps for the same code. That's a giant
pain, but I think @miniksa Michael Niksa FTE is working on that.

TerminalApp is literally the only one I cannot get to work with a shared PCH. So if you're making more of them, you're effectively undoing all the work I'm doing right now to share a PCH among the other things. Why does this have to be done?

@zadjii-msft
Copy link
Member Author

thank god

@zadjii-msft zadjii-msft deleted the dev/migrie/f/de-refactor branch January 31, 2020 14:19
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.

3 participants