-
Notifications
You must be signed in to change notification settings - Fork 3.3k
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
Comments
Yes, these are the posix_proxy tool code. What would be the problem here? |
Raw c++ sources shouldn't be just dropped among libraries. |
What would be a suitable location for you? |
/usr/local/bin/executable |
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 |
@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? |
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. |
But who is installing C++ sources? emscripten doesn't have an install step per-say. What "install" are you talking about? |
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:
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. |
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:
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. |
Emscripten packages exist for quite a few systems: https://repology.org/project/emscripten/versions Arch Linux, FreeBSD, Ubuntu, Homebrew, ... |
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. |
I am fine, thanks, just add the installation procedure so all users would benefit from it. |
I've opened a bug to add install procedure and generally make it easier to package emscripten: #10169. |
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. |
This changed from 1.39.4 to 1.39.5.
The text was updated successfully, but these errors were encountered: