4 ms·

Hey all, author here. Happy to take any feedback, in particular “I tried and it didn’t work out of the box” stories. I will NOT tell you to RTFM. I recommend r

• akavel 10y ago
  Am I right to understand that it's "build from anywhere" as long as "anywhere" is not Windows? (Please don't tell me about MinGW/Cygwin if the whole idea is to "make life simpler".)
  • worg 10y ago
    Anywhere in the FS of your OS From the readme: >They expect to just clone a repository anywhere, and be able to build it
  • FiloSottile 10y ago
    Sadly, correct. There is no way a standalone tool couldn't reproduce this behavior on Windows, and the eventual integrated solution definitely will, but it's just beyond the scope of hellogopher and outside my expertise.
    • e12e 10y ago
      I'm also a little confused. This is a fix for the standard go installer on platforms not setting a GOPATH, so that "go get" doesn't work without manually configuring GOPATH? Or does it actually do anything else (except "break" windows builds - or rather introduce a system complementary to "got get" that isn't quite as cross platform as go itself)?
      • FiloSottile 10y ago
        This is not about platforms (or about go get), this is about users who don't want to or know how to correctly use GOPATH. It doesn't break anything, since you can still use go get, go build, or anything that worked before. It doesn't help Windows users, but it doesn't hurt them.
        • kkirsche 10y ago
          But as of 1.8 there is a default gopath negating that
          • TheDong 10y ago
            A default gopath doesn't help a user who does "cd dev; git clone https://github.com/coolprojects/project; https://github.com/coolprojects/project; cd project; go build" (or make) The default gopath does not help there. Sure, if a user knows how to use go's insane global-project-directory-bullshit then they don't need this, but since it's a go-specific bullshit, they might not. Every sane language lets you have a directory where you want for each unrelated project. Only go dictates some crazy tree and defaults to creating it for you in $HOME
            • e12e 10y ago
              Right. But in order to build a go project, you need the go compiler. And the go compiler comes with "go get". So my question was more: if a user has installed go (properly) should not "go get" be the sane, easy, one way to install a project? And isn't "fixing" "go get" better than adding a dependency on make? (and I guess this project in a sense is a way to fix "go get", but it seems thrasher fragile; any one project might end up with a broken makefile by accident)..
    • akavel 10y ago
      A batch or PowerShell script potentially could (and it could even be named make.bat, so that instructions would stay the same). Windows does actually support symlinks, though the caveat is that it requires elevated privileges. See e.g.: https://en.wikipedia.org/wiki/NTFS_symbolic_link https://en.wikipedia.org/wiki/NTFS_symbolic_link. I suppose some PowerShell magic could invoke the Admin password prompt, though there's also a question whether it'd be good to condition users to require elevated privileges for some random just downloaded script.
• reledi 10y ago
  Thanks for making this, hope it catches on. As a non-gopher, whenever I came across a project where I needed to build a Go binary I'd get blocked by the GOPATH and since then I've just avoided such projects.
• lunixbochs 10y ago
  I did something similar for one of my projects (github.com/lunixbochs/usercorn) if you want another perspective. My primary goal was `make` would work out of the box in most environments (on OS X / Linux), even if you did not have Go installed at all. This includes downloading the Go binaries for your platform, building three C libraries, fixing gopath, and automatically determining packages for `go get`. https://github.com/lunixbochs/usercorn/blob/master/Makefile https://github.com/lunixbochs/usercorn/blob/master/Makefile