guile: update to 3.0.8; add PPC patch

[barracuda156]

Description

Long due version update for guile, patch for ppc32.

Type(s)

• [ ] bugfix
• [x] enhancement
• [ ] security fix

Tested on

macOS 10.6.8 Server Xcode 3.2.6

macOS 10.6 PPC Xcode 3.2

P. S. Please feel free to amend custom settings for older systems. Some of the ones set to disabled may work. Building the new guile takes more than 10 hrs on G5 Quad, so I just borrowed args which I used to build @2.9.9 earlier. Some of the settings in Portfile are inherited from the ancient @2.2.2 and may be redundant.

[barracuda156]

@kencu The port has no maintainers, so I guess we have to decide anyway. guile is stuck on the very old version (and on PPC it didn’t even build as-is).

[barracuda156]

Looks like there is a problem with parsing the ending portion of the portfile where a part is commented out inside brackets. I will fix that today.

[barracuda156]

@kencu @catap Alternatively, we may either move an old guile to guile2 or the new one to guile3.

[catap]

@barracuda156 does any port depends on guile? And if so, can it be built with your update?

[barracuda156]

@barracuda156 does any port depends on guile? And if so, can it be built with your update?

@catap Not many; with a previous @2.9.9 (which in fact reports itself as @3.0) I have built gnotime and swig3-guile, with patching config to look for a correct guile version.

@kencu On a side note, why does the macos-10.15 bot report this error?

find: /tmp/mpbb: No such file or directory
[11](https://github.com/macports/macports-ports/runs/6059903717?check_suite_focus=true#step:9:11)
Error: Process completed with exit code 1.

What does that even mean? )

[barracuda156]

@kencu Okay, another ten hours, and I can confirm that --enable-shared works, and in fact is necessary for dependencies to build. I have enabled it in the portfile. gnotime has build successfully using guile @3.0.8.

[barracuda156]

@kencu @catap Alternatively, we may either move an old guile to guile2 or the new one to guile3.

That would be great! Usually, the way this works is the current port has the default name, in this case "guile" and an older version left behind to support some port that needs that version still has a versioned name like "guile18" or "guile2" or "guile22" or something like that.

In the case of guile, the last time somebody tried to roll out an older version (guile18) it turned out to be more complicated than expected https://github.com/macports/macports-ports/blob/master/lang/guile18/Portfile but perhaps all the new stuff in MacPorts since then will make it easier to make a guile2 port.

@kencu I agree that making an old version as guile2 appears to be a better idea. Technically it is straightforward, we literally copy the existing portfile into a new port. Should I do that? (Can I even commit a new port?)

[kencu]

@kencu I agree that making an old version as guile2 appears to be a better idea. Technically it is straightforward, we literally copy the existing portfile into a new port. Should I do that? (Can I even commit a new port?)

It's a bit more complicated. The new guile2 port has to be

1. installed somewhere other than the default place guile is installed
2. not collide with the guile18 or new guile port
3. still has to be able to be found by the ports that need to use it when they try to build.

[barracuda156]

@kencu I agree that making an old version as guile2 appears to be a better idea. Technically it is straightforward, we literally copy the existing portfile into a new port. Should I do that? (Can I even commit a new port?)

It's a bit more complicated. The new guile2 port has to be

1. installed somewhere other than the default place guile is installed
2. not collide with the guile18 or new guile port
3. still has to be able to be found by the ports that need to use it when they try to build.

@kencu Got it. Can someone take care of that? These are nuances specific to Macports internals, which I am not aware of. Or if there is a transparent step-wise instruction, I can do that, of course. I will also appreciate if someone can test guile @3.0.8 on a relevant Intel system. I would imagine building on PPC is more problematic, and on Intel every option gonna work as-is, but better be safe.

[barracuda156]

Building guile @3.0.8 now on 10.6.8 Rosetta, will leave it to compile overnight, but so far all looks good.

[harens]

On a side note, why does the macos-10.15 bot report this error?

find: /tmp/mpbb: No such file or directory
[11](https://github.com/macports/macports-ports/runs/6059903717?check_suite_focus=true#step:9:11)
Error: Process completed with exit code 1.

What does that even mean? )

By default, when a GitHub action fails, any workflows that are still running are cancelled. Running more tests doesn't help much when there are already errors to fix. It's more useful to have the bots running on other PRs.

The macOS 11 build failed, so the 10.15 build was cancelled. Hence the obscure error :)

[barracuda156]

guile @3.0.8 successfully built on 10.6.8 Rosetta:

macmini:~ svacchanda$ port -v installed guile
The following ports are currently installed:
  guile @3.0.8_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2022-04-21T02:27:46+0800'

Took a while, since in VM.

[barracuda156]

@kencu @harens Dependencies fixed, guile builds on bots now.

[barracuda156]

@mascguy @kencu Do we have reservations with this update? Or should it rather be turned into guile-devel or guile3? I am perfectly fine with either of the options, as you guys see optimal for Macports.

[kencu]

I am in charge of nothing, but unless the above comments about making a guile2 port happen are done then many things will break I think.

[barracuda156]

I am in charge of nothing, but unless the above comments about making a guile2 port happen are done then many things will break I think.

What do you think a painless transition could be? Maybe a technically easier, though perhaps less consistent, would be just introduce guile3 for the time-being, until everything is confirmed to build with it? In such a case no extra PRs required immediately, nothing gonna break.

[barracuda156]

Both OpenBSD and NetBSD decided to keep all three major versions of Guile as separate ports: https://github.com/NetBSD/pkgsrc/tree/trunk/lang https://github.com/openbsd/ports/tree/master/lang

[catap]

@barracuda156 just an idea split it into commits:

• rename glue -> glue2
• updated dependencies to use glue2
• introduce glue3

[barracuda156]

@barracuda156 just an idea split it into commits:

• rename guile -> guile2
• updated dependencies to use guile2
• introduce guile3

@mascguy @kencu WDYT?

[mascguy]

@barracuda156 just an idea split it into commits:

• rename guile -> guile2
• updated dependencies to use guile2
• introduce guile3

@mascguy @kencu WDYT?

Sounds reasonable, but I haven't had a chance to review all of the details and prior discussion.

@kencu?

[kencu]

@barracuda156 just an idea split it into commits:

• rename glue -> glue2
• updated dependencies to use glue2
• introduce glue3

this was always the recommended plan, but turned out to be harder than it looks when previously tried.

see my june 10 comment above, for one example

[kencu]

oh, whether the newest guile is numbered or not is a small thing. Parallel installs of the various guile versions was the thing thst takes a bit of coding for someone

[barracuda156]

oh, whether the newest guile is numbered or not is a small thing. Parallel installs of the various guile versions was the thing thst takes a bit of coding for someone

What example do we have to avoid conflicts in such cases?

[catap]

@barracuda156 I suggest to start to figure out: did glue2 and glue3 had compatibily API? If no => separated ports. If yes => you may simple update the port. If ABI is different => you must increase revision of all ports which is depends on it.

[barracuda156]

@barracuda156 I suggest to start to figure out: did glue2 and glue3 had compatibily API? If no => separated ports. If yes => you may simple update the port. If ABI is different => you must increase revision of all ports which is depends on it.

As the very minimum, dependents may need patches to configure scripts to recognize guile 3.x (I have done that locally for some).

[barracuda156]

Let’s see if it still builds fine, and then I will try amending guile2 accordingly.

[barracuda156]

Okay, so guile3 builds fine on Intel (CI checks fine, locally 10.6.8 x86_64 built fine), PowerPC bootstrap takes forever, currently running on a PowerMac and in Rosetta, but it built before, so should be good too.

I am gonna adopt the logic from guile18 to do the same for guile2. If that works locally, gonna finalize the PR. (May not be today, but in any case very soon.)

UPD. I think we can improve upon and reduce the trickery.

[barracuda156]

@kencu Installs fine alongside. Now we need to find out whether dependents should be made to depend on guile2 or the new one.

macmini:bin svacchanda$ sw_vers
ProductName:	Mac OS X Server
ProductVersion:	10.6.8
BuildVersion:	10K549
macmini:bin svacchanda$ ./port -v installed | grep guile
  guile @3.0.8_0 (active) requested_variants='' platform='darwin 10' archs='x86_64' date='2022-11-03T18:40:05+0800'
  guile2 @2.2.7_3 (active) requested_variants='' platform='darwin 10' archs='x86_64' date='2022-11-03T21:20:37+0800'

[kencu]

to test your proposal, you might install only your guile2 port, and no other guiles, and then see if any of the current ports that depend on guile can be made to find it.

Then, install the new guile, and make sure ports configured to use the guile2 port don’t accidentally find and use the new guile instead.

[barracuda156]

@kencu What is desirable, to begin with? Would we rather move to new guile whatever builds with it – or we want to set all current dependents to use guile2?

P. S. What builds I can test on Intel. On PPC it will likely involve another 4 months of fixing ports in the process LOL.

If anyone eager to test these, now it should be possible (on x86_64 at least – I am not sure guile2 builds for ppc).