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
{{ message }}
This repository has been archived by the owner on Oct 19, 2019. It is now read-only.
I'm not an expert at V8 or Go, so forgive me if this is naive, but it seems like one of the pain points of v8worker is that it requires that users run make and therefore doesn't build with a simple go build (as seems to be standard in Go projects these days). This means that downstream projects can't use go build for their build system, as well as their downstream projects, and so on.
If you're open to it, I'd like to explore alternatives to the current solution. If any of them sound acceptable, I can do the legwork myself to implement it. Below are a few as I see them, please correct me if I'm wrong on something -- like I said, new to go, new to V8.
Allow users to build against system installations of V8, instead of building it specifically for the solution. This might require code changes to the C code that uses V8 to make it more compatible with later versions, or we might have to state our version dependencies right up front. We'll also have to figure out how we want to handle the pkg-config stuff we're generating -- I don't know the answer to that off the top of my head, aside from using more static flags in our cgo calls.
Add v8worker to the usual package manager suspects -- brew, apt-get, etc. Labor-intensive, and annoying to maintain, but possibly worth it. Nonstandard for go, but at least it is compatible with go build and involves only a few more commands, to get the packages themselves.
Add some support for v8worker "distributions", which possibly would avoid the problems of configuring and generating the configuration stuff, like pkg-config, but not the problem of building V8 itself. This could be used in conjunction with the first option.
Open to other suggestions as well. Let me know what you think.
The text was updated successfully, but these errors were encountered:
(It is additionally worth noting that I did check the Issues history and did see that initially v8worker did rebundle the whole V8 dependency, to avoid making people install depot tools. This is why I didn't suggest that as an option.)
Hi -
Sure, I'm all for eliminating the makefile.
I don't want dependence on brew or apt-get - it's outside the scope of this project. People who use this project are programmers and know how to install things (and may be particular about how they install things - personally I don't use brew on my macintosh)
As for linking to to system installed v8, I'm fine with if you have that need (i.e. you're a debian packager) otherwise I'd rather avoid the complexity now.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I'm not an expert at V8 or Go, so forgive me if this is naive, but it seems like one of the pain points of v8worker is that it requires that users run
make
and therefore doesn't build with a simplego build
(as seems to be standard in Go projects these days). This means that downstream projects can't usego build
for their build system, as well as their downstream projects, and so on.If you're open to it, I'd like to explore alternatives to the current solution. If any of them sound acceptable, I can do the legwork myself to implement it. Below are a few as I see them, please correct me if I'm wrong on something -- like I said, new to go, new to V8.
brew
,apt-get
, etc. Labor-intensive, and annoying to maintain, but possibly worth it. Nonstandard forgo
, but at least it is compatible withgo build
and involves only a few more commands, to get the packages themselves.Open to other suggestions as well. Let me know what you think.
The text was updated successfully, but these errors were encountered: