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

Cleanup unused 3rd-party build system variables #4

Open
trueqbit opened this issue Jan 2, 2020 · 3 comments
Open

Cleanup unused 3rd-party build system variables #4

trueqbit opened this issue Jan 2, 2020 · 3 comments
Assignees

Comments

@trueqbit
Copy link
Collaborator

trueqbit commented Jan 2, 2020

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:

<LIBXML_INC>$(LIB_ROOT)\libxml2-2.9.0\include</LIBXML_INC>
<LIBXML_LIB>$(LIB_ROOT)\libxml2-2.9.0\lib\x64</LIBXML_LIB>
<LIBXML_BIN>$(LIB_ROOT)\libxml2-2.9.0\bin\x64</LIBXML_BIN>
@rimmartin
Copy link
Owner

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

@trueqbit
Copy link
Collaborator Author

trueqbit commented Jan 3, 2020

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 :) ).

@rimmartin
Copy link
Owner

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

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