code review 5375049: misc/osx: Add scripts to create OS X package and disk image

misc/osx: Add scripts to create OS X package and disk image

Fixes issue 2327.

[bytbox, 2011-11-11 15:06:37]

Hello golang-dev@googlegroups.com (cc: golang-dev@googlegroups.com),

I'd like you to review this change to
http://go.googlecode.com/hg

[bytbox, 2011-11-11 15:08:46]

This is most likely unready for merging (files for various editors in misc/ need
to be put into place, etc.), but I figured there's enough to get started here.

[rsc, 2011-11-11 19:53:56]

Does it make sense to put the stuff in /opt or does
it make more sense to have /Applications/Go?
That's where I'd look if I wanted to uninstall.

Russ

[bytbox, 2011-11-11 20:02:21]

On 11/11/11 14:53, Russ Cox wrote:
> Does it make sense to put the stuff in /opt or does
> it make more sense to have /Applications/Go?
> That's where I'd look if I wanted to uninstall.

/Applications/Go makes sense if Go was a .app meant to be executed 
outside of terminal. Putting GOROOT there would confuse any tool 
scanning Applications for things to show to the user, such as spotlight.

Developer tools are usually spread loosely throughout /Developer - in 
the future, that may be the logical destination for the installation. At 
the moment, there's not any benefit derived from doing that, (no tools 
anyone might use are expecting us to do that) and it would make the 
installation considerably more complicated, since there could no longer 
be a single GOROOT.

Putting things in /opt on macs is common enough; I think at this stage 
it's the best option (even though it is kind of a cheat to avoid having 
to deal with the strict semantics of /Developer).

-- 
Scott Lawrence

[rsc, 2011-11-11 20:11:07]

The only thing in /opt on my Mac is X11.
No matter how you look at it, Go is not like X11.

What are the strict semantics of /Developer?

Russ

[bytbox, 2011-11-11 20:39:26]

On 11/11/11 15:11, Russ Cox wrote:
> The only thing in /opt on my Mac is X11.
> No matter how you look at it, Go is not like X11.

That's funny; I appear to have X11 under /Developer(/usr/X11).

>
> What are the strict semantics of /Developer?

Details below. It looks like /Developer/SDKs would be the appropriate 
place to stick GOROOT, if it couldn't be split up - that's where the 
android sdk goes, at least.

Supposedly apple has a guidelines document which specifically discusses 
/Developer, but I can't seem to find it. What I can find

http://developer.apple.com/library/mac/#documentation/FileManagement/Conceptu...

Doesn't say much that's helpful - it does mention unix directories as 
being "helpful to developers".

Roughly, this is what it appears to be (disclaimer: this is all tainted 
by my own experience and what tools I use - other tools may attach more 
or less meaning to these directories):

  - Applications: GUI stuff for developers. .app format. Not for us (yet).
  - Documentation: obvious. Matters at least to spotlight (at least 
empirically, with my configuration); probably to XCode as well.
  - Examples: equally obvious; less important. If examples are in 
Documentation, that's ok.
  - Extras: miscellaneous. This seems to be mostly used for demos (see 
PreferencePanes for example)
  - Headers: obvious; not for us
  - Library: this seems to be meant to be used by applicatons as a place 
to store their backend - including both preferences and underlying 
frameworks.
  - Makefiles: I think XCode likes to use this underneath, but I'll 
admit I don't know.
  - Platforms: .platform-formatted folders, probably Xcode et al. expect 
something special from this (lots of badly-designed plist excrement).
  - SDKs: Complete, bundled SDKs. Except for the android sdk, everything 
I have here obeys a plist-ridden format, presumably for the benefit of 
Xcode et al. The android SDK doesn't; I'd imagine we're most like them.
  - Tools: I only have things installed by CPlusTest in here, so this 
might not be real.

I also have /Developer/usr - I'm not sure if that's actually supposed to 
be there, or if it's just leftover from macports or similar.

-- 
Scott Lawrence

[roberto_costumero.es, 2011-11-11 21:11:38]

On Fri, Nov 11, 2011 at 21:39, Scott Lawrence <bytbox@gmail.com> wrote:

> On 11/11/11 15:11, Russ Cox wrote:
>
>> The only thing in /opt on my Mac is X11.
>> No matter how you look at it, Go is not like X11.
>>
>
> That's funny; I appear to have X11 under /Developer(/usr/X11).


Me too. Though there's no /opt directory on Lion.


>
>
>
>> What are the strict semantics of /Developer?
>>
>
> Details below. It looks like /Developer/SDKs would be the appropriate
> place to stick GOROOT, if it couldn't be split up - that's where the
> android sdk goes, at least.
>
> Supposedly apple has a guidelines document which specifically discusses
> /Developer, but I can't seem to find it. What I can find
>
> http://developer.apple.com/**library/mac/#documentation/**
> FileManagement/Conceptual/**FileSystemProgrammingGUide/**
>
FileSystemOverview/**FileSystemOverview.html<http://developer.apple.com/library/mac/#documentation/FileManagement/Conceptual/FileSystemProgrammingGUide/FileSystemOverview/FileSystemOverview.html>
>
> Doesn't say much that's helpful - it does mention unix directories as
> being "helpful to developers".
>
> Roughly, this is what it appears to be (disclaimer: this is all tainted by
> my own experience and what tools I use - other tools may attach more or
> less meaning to these directories):
>
>  - Applications: GUI stuff for developers. .app format. Not for us (yet).
>  - Documentation: obvious. Matters at least to spotlight (at least
> empirically, with my configuration); probably to XCode as well.
>  - Examples: equally obvious; less important. If examples are in
> Documentation, that's ok.
>  - Extras: miscellaneous. This seems to be mostly used for demos (see
> PreferencePanes for example)
>  - Headers: obvious; not for us
>  - Library: this seems to be meant to be used by applicatons as a place to
> store their backend - including both preferences and underlying frameworks.
>  - Makefiles: I think XCode likes to use this underneath, but I'll admit I
> don't know.
>  - Platforms: .platform-formatted folders, probably Xcode et al. expect
> something special from this (lots of badly-designed plist excrement).
>  - SDKs: Complete, bundled SDKs. Except for the android sdk, everything I
> have here obeys a plist-ridden format, presumably for the benefit of Xcode
> et al. The android SDK doesn't; I'd imagine we're most like them.
>  - Tools: I only have things installed by CPlusTest in here, so this might
> not be real.
>
> I also have /Developer/usr - I'm not sure if that's actually supposed to
> be there, or if it's just leftover from macports or similar.
>
> --
> Scott Lawrence
>

I've got Go installed on three different paths:

/usr/local - Thought in the first place it would be nice to have it
installed there as it is related to usr space and something "extra" I
added. There it's where git or LaTeX install by default.

/Developer/Go - Then I thought it would be nice to have all my developer
tools together. And I still think it would be a nice place to put Go, but
one of the updates of XCode broke my Go installation.

Now I've got it installed in a path inside my home directory, cause it's
where I've placed all my big projects and on the migration to Lion didn't
know what to do with Go.

If there is no problem /Developer should be Go's home with a .dmg
installer, but /usr/local seems like a good candidate to me.

[rsc, 2011-11-11 21:27:44]

/usr/local/go is fine with me.

[bytbox, 2011-11-11 21:28:54]

On 11/11/11 16:27, Russ Cox wrote:
> /usr/local/go is fine with me.

Here too; will do.

-- 
Scott Lawrence

[bytbox, 2011-11-17 22:39:13]

Hello golang-dev@googlegroups.com, rsc@golang.org, roberto@costumero.es (cc:
golang-dev@googlegroups.com),

Please take another look.

[bytbox, 2011-11-17 22:42:56]

The installer now works sanely (complete installation requires no user
intervention) and puts XCode files into place when xcode is installed
- probably ready for merging. Installation is GOROOT=/usr/local/go

On Thu, Nov 17, 2011 at 17:39,  <bytbox@gmail.com> wrote:
> Hello golang-dev@googlegroups.com, rsc@golang.org, roberto@costumero.es
> (cc: golang-dev@googlegroups.com),
>
> Please take another look.
>
>
> http://codereview.appspot.com/5375049/
>



-- 
Scott Lawrence

[Joe Poirier, 2011-11-18 05:29:29]

On Thu, Nov 17, 2011 at 4:42 PM, Scott Lawrence <bytbox@gmail.com> wrote:
> The installer now works sanely (complete installation requires no user
> intervention) and puts XCode files into place when xcode is installed
> - probably ready for merging. Installation is GOROOT=/usr/local/go
>
> On Thu, Nov 17, 2011 at 17:39,  <bytbox@gmail.com> wrote:
>> Hello golang-dev@googlegroups.com, rsc@golang.org, roberto@costumero.es
>> (cc: golang-dev@googlegroups.com),
>>
>> Please take another look.
>>
>>
>> http://codereview.appspot.com/5375049/
>>
>
>
>
> --
> Scott Lawrence
>

Worked great on my MBP running 10.6.8.

The packager builds the toolchain but I think the plan is to have the
dashboard builder call the packager after the toolchain has already
been built (for designated builds, e.g. releases).

-joe

[bytbox, 2011-11-18 13:01:36]

On 11/18/11 00:28, Joseph Poirier wrote:
> Worked great on my MBP running 10.6.8.
>
> The packager builds the toolchain but I think the plan is to have the
> dashboard builder call the packager after the toolchain has already
> been built (for designated builds, e.g. releases).

Sounds good; if that's so, the re-building can be skipped.

This is, of course, still wildly untested - every machine that's ever 
run it (as far as I know) was an MBP running 10.6.8. No idea if Lion's 
different enough to cause problems.

-- 
Scott Lawrence

[rsc, 2011-11-18 23:36:04]

Once it is checked in I will be happy to try it on Lion.

[Joe Poirier, 2011-11-19 01:05:59]

*** Submitted as http://code.google.com/p/go/source/detail?r=d34288abcb3b ***

misc/osx: Add scripts to create OS X package and disk image

Fixes issue 2327.

R=golang-dev, rsc, roberto, jdpoirier
CC=golang-dev
http://codereview.appspot.com/5375049

Committer: Joe Poirier <jdpoirier@gmail.com>