goffice: update to 0.10.6

[c.herbig@…]

Updates to new 0.10.5 release, and incorporates a quartz variant for gtk-osx-application support. I took the liberty of cc-ing devans, since devans is doing most of the new gnome related stuff.

[ryandesign (Ryan Carsten Schmidt)]

When the version is increased, the revision should drop to 0.

[c.herbig@…]

removed revision number

[c.herbig@…]

Update for the brand new goffice 0.10.6

[ryandesign (Ryan Carsten Schmidt)]

I see now goffice has a subport goffice08, which did not specify its own revision, therefore it inherited revision 1 from the main port, therefore it needs to stay at revision 1. Does the new quartz variant work with the goffice08 subport? The patch doesn't apply so I assume not, in which case it should be inside an "if {${name} eq ${subport}}" block to make it apply only to the main goffice port. In fact a lot of the goffice port should be inside such a block so as not to leak definitions into the subport. Committed in r110210.

[c.herbig@…]

Replying to ryandesign@…:

I see now goffice has a subport goffice08, which did not specify its own revision, therefore it inherited revision 1 from the main port, therefore it needs to stay at revision 1

Ok.

Does the new quartz variant work with the goffice08 subport?

It doesn't need gtk-osx-application to be quartz compatible, since that is handled by gtk3, but there is supposed to be a way to coax Gnumeric into using the OS X menu bar via gtk-osx-application, and apparently this is handled by goffice. I'm still looking into it. Since goffice08 is old, I wasn't going to waste any time on that one.

The patch doesn't apply so I assume not, in which case it should be inside an "if {${name} eq ${subport}}" block to make it apply only to the main goffice port. In fact a lot of the goffice port should be inside such a block so as not to leak definitions into the subport.

... um... ok.

[larryv (Lawrence Velázquez)]

Replying to c.herbig@…:

Replying to ryandesign@…:

The patch doesn't apply so I assume not, in which case it should be inside an "if {${name} eq ${subport}}" block to make it apply only to the main goffice port. In fact a lot of the goffice port should be inside such a block so as not to leak definitions into the subport.

... um... ok.

You could also use a subport block.

subport ${name} {
    variant quartz {}
}

I generally prefer this style, when I can get away with it.

[ryandesign (Ryan Carsten Schmidt)]

That's what I did when I first started using subports, then Joshua told me the subport code in base was never designed to accommodate that usage (i.e. declaring a subport for ${name}) and might not work correctly, so I stopped doing that. I don't remember if base was subsequently changed to accommodate that or not.

[c.herbig@…]

Replying to ryandesign@…:

That's what I did when I first started using subports, then Joshua told me the subport code in base was never designed to accommodate that usage (i.e. declaring a subport for ${name}) and might not work correctly, so I stopped doing that. I don't remember if base was subsequently changed to accommodate that or not.

I've never seen any of that before, and subport is not documented in the documentation pages, or at least the last time I checked, when I split off goffice08 a few months ago. Either way, I suppose I really ought to just send the patch and info to the gnumeric/goffice developers.