Open trueqbit opened 4 years ago
Hi @trueqbit,
You think this should be done before making windows travis successful and publishing as is for one pass? So people have it as they are familiar. And then clean up?
I have an old windows box I'm trying to stand up again to better go after the travis windows build
I have seen your effort! If you intend a release it's probably good to wait with my changes (unless targeting windows with travis builds is a never-ending story :) ).
yea:-) I got windows working on another project https://github.com/rimmartin/saxon-node It can be done; but the cmake stuff in this project I'm not as familiar with
It looks like original pion was designed for re-purposing the whole project for your custom webserver. To the contrary I am trying to use it like a 3rd-party dependency. As such, I am building pion outside of my project, then pull it in.
Now, basing a webserver on a complete webserver stack will always lead to a strong dependency on the specific framework. But at least my own code shouldn't be entangled. It makes developing pion and pulling in new stuff much easier.
That's why I propose to remove all build-related variables (macros) of 3rd-party libraries (for include/link paths) not used by pion itself - they should be pulled in by the custom projects themselves, especially now that there are C++ library/package managers available, vcpkg or conan, just to mention a few.
List of libraries:
I myself can only speak confidently about the Visual C++/MSBuild build system. It seems that other build system scripts don't "suffer" from this mess to this extent - I have only seen bzip2.
So, e.g. I would remove from _build/third_party_libsx64.props: