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

WIN32 Glew and DLL fixes to CMakeLists.txt #905

Closed
wants to merge 2 commits into from

Conversation

jcowles
Copy link
Contributor

@jcowles jcowles commented Oct 27, 2016

Previously, dynamic targets were disabled on Windows due to configuration
errors in the CMake install targets. In addition, glew was forced to
static linkage on windows, even when dynamic Glew libraries were linked
which would result in linker errors.

In this change, static glew libraries are detected by looking for the "s"
suffix convention on the library (though, maybe this should be handled in
the FindGlew module).

In addition, there is now a fork in the opensubdiv osd_dynamic_{cpu|gpu}
install targets to account for the Windows DLL CMake quirks.

Previously, dynamic targets were disabled on Windows due to configuration
errors in the CMake install targets. In addition, glew was forced to
static linkage on windows, even when dynamic Glew libraries were linked
which would result in linker errors.

In this change, static glew libraries are detected by looking for the "s"
suffix convention on the library (though, maybe this should be handled in
the FindGlew module).

In addition, there is now a fork in the opensubdiv osd_dynamic_{cpu|gpu}
install targets to account for the Windows DLL CMake quirks.
@jcowles
Copy link
Contributor Author

jcowles commented Oct 27, 2016

/CC @meshula

This does not cause build issues, though removing it from
the public header is good hygiene.
@davidgyu
Copy link
Member

davidgyu commented Dec 9, 2016

Hey Jeremy! Thanks again for the PR & CLA

I'm going to cherry pick this but exclude the changes related to osd_dynamic_{cpu,gpu} install and exe linking. Those are the parts of the PR which are causing the AppVeyor failures (which also repro for me locally).

There's more work that we need to do to really support DLL builds, e.g. symbol exports, distinct names for the static and dynamic .libs, etc.

@davidgyu
Copy link
Member

davidgyu commented Jan 6, 2017

Closing this in favor of #961

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.

2 participants