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

VS2008 building in IDE #23

Open
colindavidfoster opened this issue Dec 19, 2016 · 2 comments
Open

VS2008 building in IDE #23

colindavidfoster opened this issue Dec 19, 2016 · 2 comments

Comments

@colindavidfoster
Copy link

colindavidfoster commented Dec 19, 2016

When building the VS2008 solution (and possibly others) a minimum of Windows SDK v7 is required. This manifests itself as failure to find VER_SUITE_WH_SERVER when building. In my case changing the VS2008 from v6 to v7 solved the problem

WTL seems to be a pre-requisite for building. I couldn't find this mentioned in the documentation, but maybe I missed it.

The project and/or solution files mention the $platform and $configuration macros, these should be $platformname and $configurationname otherwise the various build overwrite each other

When building for, say, DEBUG, the client code links against zlibSD.lib but the zlib build only produces zlib.lib. Changing the output name approriately for a given build solved this.

It could be that I'm being naive about the above issues, but it seems as though building using CI scripting doesn't guarantee that the IDE builds will work without tweaking. :-(

@bchavez
Copy link
Owner

bchavez commented Dec 19, 2016

I think you have the right picture @colindavidfoster . The CI server scripted build takes precedence over a straight shot F5 build from Visual Studio.

If you'd like to make some changes to make it easier to build from Visual Studio that does not compromise CI server's build integrity I think the community would be open to those kinds of changes.

I think we would prefer any changes to be minimal in nature, if at all possible.

@colindavidfoster
Copy link
Author

colindavidfoster commented Dec 19, 2016

OK I'll see what I can come up with. I'll probably take is slow as all my Git work so far has been in house. Contributing to an external project will be a new experience

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

No branches or pull requests

2 participants