Re: Antlr: Rebuild on 12.x86_64

[Nils Breunese]

You can use the java PortGroup 
(https://guide.macports.org/chunked/reference.portgroup.html#reference.portgroup.java)
 to specify a minimum required Java version, and a fallback port to install 
when this minimum version is not already available.

Nils.

> Op 5 feb 2024 om 07:42 heeft Joshua Root  het volgende 
> geschreven:
> 
> On 5/2/2024 16:10, Dave Allured - NOAA Affiliate via macports-dev wrote:
>> Would someone with builder access please trigger a rebuild of antlr on the 
>> 12.x86_64 builder?  There seems to be a difference between builders and 
>> github CI, and I need to check a recent builder log file.  Thanks for your 
>> help.
> 
> I don't think there's any need to run a build; the issue (or at least the 
> first one encountered) is that antlr needs Java, the antlr port doesn't 
> depend on any Java port, and recent macOS versions don't ship Java in a 
> default installation.
> 
> The CI image on the other hand does have Java installed. 
> 
> 
> - Josh

Re: Antlr: Rebuild on 12.x86_64

[Joshua Root]

On 5/2/2024 16:10, Dave Allured - NOAA Affiliate via macports-dev wrote:
Would someone with builder access please trigger a rebuild of antlr on 
the 12.x86_64 builder?  There seems to be a difference between builders 
and github CI, and I need to check a recent builder log file.  Thanks 
for your help.


I don't think there's any need to run a build; the issue (or at least 
the first one encountered) is that antlr needs Java, the antlr port 
doesn't depend on any Java port, and recent macOS versions don't ship 
Java in a default installation.


The CI image on the other hand does have Java installed. 



- Josh

Antlr: Rebuild on 12.x86_64

[Dave Allured - NOAA Affiliate via macports-dev]

Would someone with builder access please trigger a rebuild of antlr on the
12.x86_64 builder?  There seems to be a difference between builders and
github CI, and I need to check a recent builder log file.  Thanks for your
help.

Re: Testing a modified portgroup

[Joshua Root]

On 5/2/2024 14:58, Austin Ziegler wrote:
I think I have found a bug in the golang portgroup, and I think I have 
an idea on how to fix it, but I'm not sure how to test such a modification.


You'd make the change in your local copy of the ports tree and check 
that a port affected by the bug now works correctly, and that some 
existing ports still work correctly.


For those interested, it's in go._translate_package_id. If I have a 
package ID github.com/jmespath/go-jmespath/internal/testify 
, the 
*subproject* is internal/testify, not internal. But the line `set 
subproject [lindex ${parts} 3]` will *only* grab `internal`.


So this:

```tcl
     set parts [split ${package_id} /]

     set domain [lindex ${parts} 0]
     set author [lindex ${parts} 1]
     set project [lindex ${parts} 2]
     # possibly empty
     set subproject [lindex ${parts} 3]
```

Should probably be this:

```tcl
set parts [split $package_id /]

set domain [lindex $parts 0]
set author [lindex $parts 1]
set project [lindex $parts 2]
# Join the remaining parts to get the full subproject path
if {[llength $parts] > 3} {
     set subproject [join [lrange $parts 3 end] /]
} else {
     set subproject ""
}
```


This could be simplified further to something like:

set parts [split $package_id /]
set remaining_parts [lassign $parts domain author project]
set subproject [join $remaining_parts /]

- Josh

Testing a modified portgroup

[Austin Ziegler]

I think I have found a bug in the golang portgroup, and I think I have an
idea on how to fix it, but I'm not sure how to test such a modification.

For those interested, it's in go._translate_package_id. If I have a
package ID
github.com/jmespath/go-jmespath/internal/testify, the *subproject* is
internal/testify, not internal. But the line `set subproject [lindex
${parts} 3]` will *only* grab `internal`.

So this:

```tcl
set parts [split ${package_id} /]

set domain [lindex ${parts} 0]
set author [lindex ${parts} 1]
set project [lindex ${parts} 2]
# possibly empty
set subproject [lindex ${parts} 3]
```

Should probably be this:

```tcl
set parts [split $package_id /]

set domain [lindex $parts 0]
set author [lindex $parts 1]
set project [lindex $parts 2]
# Join the remaining parts to get the full subproject path
if {[llength $parts] > 3} {
set subproject [join [lrange $parts 3 end] /]
} else {
set subproject ""
}
```

-a
-- 
Austin Ziegler • halosta...@gmail.com • aus...@halostatue.ca
http://www.halostatue.ca/ • http://twitter.com/halostatue

Re: Lazarus package update

[Karl-Michael Schindler]

> Am 04.02.2024 um 13:00 schrieb Joshua Root 
> Message-ID: <504d687e-9e2d-44f7-8198-e0f51c76e...@macports.org>
> 
> If the new version breaks compatibility, and if the dependents have not 
> all been updated to work with the new version, then you need a second 
> port. But preferably the old version should be lazarus2 and lazarus 
> should continue to be the latest version.
> 
> If none of the dependents work with the new version yet, then you should 
> probabl wait until a significant number do before updating.
> 
> - Josh

Ah. Good points. Lazarus' only dependent in MacPorts is ddrescueview, 
maintained by myself. Should be easy to handle. I am still a bit worried, 
because Lazarus is more of a ready to use IDE for Pascal programming outside of 
MacPorts. Therefore, for judging the actual impact of an update, I should 
probably check the Lazarus user forums. Besides, my first try got stuck with a 
glitch.

Thanks again - Michael.