You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
libxml2
iconv
icu
bzip2
yajl
python
sqlite
(possibly, though required for spdy) zlib
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_libs_x64.props:
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_libs_x64.props:
The text was updated successfully, but these errors were encountered: