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

C++ sources installed into lib/emscripten/tools/websocket_to_posix_proxy #10093

Closed
yurivict opened this issue Dec 21, 2019 · 16 comments
Closed
Labels

Comments

@yurivict
Copy link

This changed from 1.39.4 to 1.39.5.

lib/emscripten/tools/websocket_to_posix_proxy/CMakeLists.txt
lib/emscripten/tools/websocket_to_posix_proxy/src/main.cpp
lib/emscripten/tools/websocket_to_posix_proxy/src/posix_sockets.h
lib/emscripten/tools/websocket_to_posix_proxy/src/sha1.cpp
lib/emscripten/tools/websocket_to_posix_proxy/src/sha1.h
lib/emscripten/tools/websocket_to_posix_proxy/src/socket_registry.cpp
lib/emscripten/tools/websocket_to_posix_proxy/src/socket_registry.h
lib/emscripten/tools/websocket_to_posix_proxy/src/threads.h
lib/emscripten/tools/websocket_to_posix_proxy/src/websocket_to_posix_proxy.cpp
lib/emscripten/tools/websocket_to_posix_proxy/src/websocket_to_posix_proxy.h
@kripken
Copy link
Member

kripken commented Dec 23, 2019

@juj Perhaps related to the sockets changes you landed in #7672 ?

@juj
Copy link
Collaborator

juj commented Dec 23, 2019

Yes, these are the posix_proxy tool code. What would be the problem here?

@yurivict
Copy link
Author

What would be the problem here?

Raw c++ sources shouldn't be just dropped among libraries.
It should be either compiled and the binary installed, or removed. Nobody would be compiling it in there in the read-only location.

@juj
Copy link
Collaborator

juj commented Dec 23, 2019

What would be a suitable location for you?

@yurivict
Copy link
Author

/usr/local/bin/executable

@juj
Copy link
Collaborator

juj commented Dec 24, 2019

Oh now I see.. I have not had anything to do with Linux system installation of Emscripten, not sure what does that and how that works. I thought you objected to the location the posix proxy tools in Emscripten repository, but now checking closer, it is in path emscripten/tools/websocket_to_posix_proxy/ (compare with e.g. emscripten/tools/optimizer/ that also contains C++ sources). Perhaps someone who authored such installation can chime in to help here.

@sbc100
Copy link
Collaborator

sbc100 commented Jan 8, 2020

@yurivict this seems like a freebsd packaging issue, no? We don't control that here upstream. I imagine you should file an issue with your distro packager maybe?

@yurivict
Copy link
Author

yurivict commented Jan 9, 2020

this seems like a freebsd packaging issue, no?

No, you are not supposed to install C++ sources. You should build them into a binary, install this binary into PREFIX/bin/, and add a section into the documentation on how to use this program.

@sbc100
Copy link
Collaborator

sbc100 commented Jan 9, 2020

But who is installing C++ sources? emscripten doesn't have an install step per-say. What "install" are you talking about?

@yurivict
Copy link
Author

yurivict commented Jan 9, 2020

emscripten doesn't have an install step per-say.

This is maybe what the problem is. You need to have the install step. Long time ago when I created the port I asked what is supposed to be installed, and came up with this:

 ${CP} -r em* cmake site src system third_party tools ${STAGEDIR}${PREFIX}/lib/${PORTNAME}

In order to have a package the project needs to install files. Alternatively, I as a port maintainer would need to be deciding what files get installed. Now I have to sort through the issues like this, and delete C++ sources that obviously shouldn't be installed.

@sbc100
Copy link
Collaborator

sbc100 commented Jan 9, 2020

As you can tell we don't currently have any support this kind of use case (turning emscripten into a package). This is mostly due to limits on our time and the fact that non-standard installation methods can end up with more complicated bug reports here in our tracker. One such package that I know of is that homebrew package. We've had a few bug reported here that relate the homebrew package and its harder for us to help such users.

Our two supported use cases for emscripten are currently:

  1. Clone from github directly
  2. Use emsdk to install

I would not object to somebody wanted to add such an install step as long as it doesn't increase our maintenance burden which is already fairly strained. I fear that doing this correctly could be lot harder than a filtered copy though.

@yurivict
Copy link
Author

yurivict commented Jan 9, 2020

Emscripten packages exist for quite a few systems: https://repology.org/project/emscripten/versions

Arch Linux, FreeBSD, Ubuntu, Homebrew, ...

@sbc100
Copy link
Collaborator

sbc100 commented Jan 9, 2020

IIUC all of these were made without the help/consultation of the emscripten developers. I'm not against improving support here, or accepting patches to make it easier.

To solve you immediate problem perhaps you could look at the install rules used those other packages? Are you the maintainer of the the freebsd port? If you'd like to co-ordinate with the other maintainers of having some kind of rule upstream I think that would be fine.

@yurivict
Copy link
Author

yurivict commented Jan 9, 2020

I am fine, thanks, just add the installation procedure so all users would benefit from it.

@sbc100
Copy link
Collaborator

sbc100 commented Jan 9, 2020

I've opened a bug to add install procedure and generally make it easier to package emscripten: #10169.

@stale
Copy link

stale bot commented Jan 8, 2021

This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 30 days. Feel free to re-open at any time if this issue is still relevant.

@stale stale bot added the wontfix label Jan 8, 2021
@stale stale bot closed this as completed Feb 7, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants