[65255] trunk/dports/lang

[Ryan Schmidt]

On Mar 24, 2010, at 15:59, David Baumgold wrote:

> On Mar 24, 2010, at 4:41 PM, Ryan Schmidt wrote:
> 
>> On Mar 24, 2010, at 15:09, singingwolfboy at macports.org wrote:
>> 
>>> +name                go-devel
>>> +set real_name       go
>>> +version             0.0.1
>> 
>>> +homepage            http://golang.org/
>>> +fetch.type          hg
>>> +hg.url              https://go.googlecode.com/hg/
>>> +hg.tag              release
>> 
>> By what means are you ensuring that version 0.0.1 is being downloaded?
> 
> As far as I can tell, Go doesn't seem to have any sort of versioning scheme yet, short of DVCS revision numbers -- which are inherently unstable, due to the distributed nature of Mercurial. I picked "0.0.1" because Macports requires a version number, and I thought it was sufficiently low that whenever Go actually does come out with a versioning scheme, it would supersede this port. I should also point out that this is intentionally a "-devel" port, and anyone who is relying on a solid, stable release with it should think twice.

Fine. But my concern is that you don't seem to be providing a guarantee that a user installing this port at point in time A will get the same software as a user installing this port at point in time B; this is a tenet all ports should uphold. I don't know how Mercurial works, but to take the example from Subversion, for a project that does not tag or branch their software, I would pick a particular revision number from their repository and put that in the portfile as "svn.revision whatever". When upstream makes changes I want to propagate to MacPorts users, I'd update the svn.revision in the portfile, and increase the version or revision so users get prompted to upgrade. Mercurial probably has a similar concept you could employ.


>> (Is there a special reason why GOBIN is set to be a directory outside of ${worksrcpath}?)
> 
> I set GOBIN outside of ${worksrcpath} because the Go install docs instruct you to check out the source code into a directory named "go" in your home directory, but they explicitly state that the default GOROOT is ~/bin -- and not, for example, ~/go/bin. Putting GOBIN outside of the worksrcpath seemed like a good way of simulating this.

Ok. There's plenty of other ports that use an out-of-source build so this is fine.


>>> +    # lib files
>>> +    xinstall -m 644 -W ${worksrcpath}/lib lib9.a libbio.a libmach.a \
>>> +        ${destroot}${prefix}/lib
>>> +    
>>> +    # include files
>>> +    file copy ${worksrcpath}/include ${destroot}${prefix}/include/${real_name}
>>> +}
>>> +
>>> +### PLATFORM VARIANTS ###
>>> +variant darwin {
>>> +    build.env-append GOOS=darwin
>>> +    test.env-append GOOS=darwin
>>> +}
>>> +variant freebsd {
>>> +    build.env-append GOOS=freebsd
>>> +    test.env-append GOOS=freebsd
>>> +}
>>> +variant linux {
>>> +    build.env-append GOOS=linux
>>> +    test.env-append GOOS=linux
>>> +}
>> 
>> My instinct is to say these should be "platform darwin", "platform freebsd" and "platform linux", though MacPorts 1.8 doesn't work so well on non-BSD OSes anymore. But I understand that this is the environment you want to develop with. So presumably you're saying you might want to develop FOR Linux ON Mac OS X, by using the +linux variant? If so, does that actually work, and is that something someone would actually want to do? It would seem to be simpler to say if you're installing with MacPorts on Mac OS X, you can only do development for Mac OS X.
> 
> I wasn't sure how the MacPorts platform system works, but I discovered that MacPorts seemed to be selecting my "darwin" and "i386" variants automatically for my development environment, so I figured that was the answer. Also, the Go docs state: "Note that $GOARCH and $GOOS identify the target environment, not the environment you are running on. In effect, you are always cross-compiling." so perhaps this is the proper solution. I'll replace "variant" with "platform" if you think that's a better choice.

It depends on your intention in providing these options, and the questions I asked above that you didn't answer. Do you expect a user with MacPorts on Mac OS X will want to do Linux or FreeBSD development, and will want to select the above +freebsd or +linux variants? If not, then "platform whatever" is correct.


>>> +variant nacl description {Platform variant} {
>>> +    build.env-append GOOS=nacl
>>> +    test.env-append GOOS=nacl
>>> +}
>> 
>> Not sure what OS this is.
> 
> This is for Google's "Native Client" platform (http://code.google.com/p/nativeclient/). The docs say that the Go port to nacl is currently incomplete, but again, this is a devel port, so I see no reason why we need to drop it. (Although this one probably should be left as a "variant" rather than a "platform".)

We don't have a platform called "nacl" in MacPorts, so you're right, "platform nacl" is out.

"Native Client is an open-source technology for running native code in web applications." Ok. So I guess it is desirable to develop for this nacl platform on Mac OS X. But it surprises me you'd have to make an either-or choice: developing for nacl, OR developing for Mac OS X, but not both.


>>> +variant amd64 description {Platform variant} {
>>> +    build.env-append GOARCH=amd64
>>> +    test.env-append GOARCH=amd64
>>> +}
>>> +variant arm description {Platform variant} {
>>> +    build.env-append GOARCH=arm
>>> +    test.env-append GOARCH=arm
>>> +}
>> 
>> I don't know what should be done with this. These look like architectures, but we don't have platforms by those names in MacPorts.
>> 
>> Should I take it that the variants i386, amd64 and arm should conflict with one another?
>> 
>> Actually, if we're going to build for the local system, then it seems you should throw out these variants, and instead set GOARCH based on the value of ${build_arch}.
> 
> I didn't know about ${build_arch} -- that makes things simpler.

It's a pretty important MacPorts concept to know about these days. :) Users have the ability to change this value in their macports.conf, and ports would do well to support this.

> (Although, for i386 machines, does ${build_arch} contain "i386" or "386"? Because Go expects the latter, not the former.)

build_arch contains ppc, ppc64, i386 or x86_64, depending on the user's system and/or macports.conf setting. Your strategy would be to inspect build_arch, and set GOARCH to a corresponding value that makes sense to Go. See the switch statement in the my_arch_to_target procedure in the minivmac port for an example of how this can be done.


>> Since I don't see any PowerPC stuff in Go, you may also want to prevent installation on PowerPC Macs. Unless again we're thinking of cross-compiling where someone could install Go on a PowerPC Mac and develop for a Intel machine. That doesn't sound like an efficient development environment however.
> 
> Agreed. How would I do that?

See the pre-fetch block in the wine port for an example.


>> +### OTHER VARIANTS ###
>>> +variant docs description {Install Go documentation} {
>>> +    post-destroot {
>>> +        xinstall -m 755 -d ${destroot}${prefix}/share/doc/
>>> +        file copy ${worksrcpath}/doc ${destroot}${prefix}/share/doc/${real_name}
>>> +        xinstall -m 644 -W ${worksrcpath} favicon.ico \
>>> +            ${destroot}${prefix}/share/doc/${real_name}
>>> +    }
>>> +}
> <snip>
>>> +default_variants +docs
>> 
>> I suggest you remove the docs variant and just integrate it into the port proper. Fewer variants is better.
> 
> Some people may want to install Go without the documentation, in order to save space on their computer. It's a legitimate choice, albeit not a very popular one these days given that disk space is so cheap. Still, the docs variant will get pulled in via default_variants, but users have the option of deselecting it. I think that's a better solution than no variant, and therefore no choice.

It's only 3.9MB of documentation. I see no reason to complicate things by offering the ability to prevent the installation of these files, especially since a user would have to remember to say "-doc" every time they upgrade this port, since otherwise "default_variants +docs" will reselect the variant.