freeciv @2.6.4_0: propose a major restructure to provide all 12 clients and utilities

[JDLH (Jim DeLaHunt)]

The present freeciv port is structured in a way which provides just a few of the 12 clients and utilities which the upstream codebase now provides. The present port is divided into two mutually incompatible sub-ports. I propose a major restructure, making a freeciv port, with variants instead of subports to include clients along with their dependencies, e.g. @gtk3 to provide the freeciv-gtk3 and freeciv-gtk3.22 clients along with a dependency on port gtk3.

The present freeciv port delivers the client freeciv-sdl2, a GUI app based on libsdl2* ports, along with command-line utilities freeciv-mp-cli, freeciv-server, and freeciv-manual.

The present freeciv-x11 port delivers the client freeciv-gtk2 and the utility freeciv-mp-gtk2, GUI apps based on the gtk2 port, along with command-line utilities freeciv-server, and freeciv-manual. Despite the port name, the GUI apps do not depend directly on X11. They depend on gtk2, and seem to work fine whether gtk2 depends on quartz or on X11.

The best clients in the current freeciv v 2.6.x codebase are freeciv-qt (dependent on Qt5) and freeciv-gtk3.22 (dependent on Gtk3). The present freeciv and freeciv-x11 ports do not deliver either of these clients.

I propose a new freeciv port, with variants based on major dependencies. One can install any combination of the variants:

freeciv base port

Delivers command-line utilities freeciv-mp-cli, freeciv-server, and freeciv-manual. Delivers man pages and documentation. Probably delivers client example code freeciv-stub, though it's not good for much.

@gtk3 variant

Delivers client freeciv-gtk3.22 and freeciv-gtk3, and utility freeciv-mp-gtk3. Depends on port gtk3. Works with gtk3@quartz or gtk3@x11.

@gtk2 variant

Delivers client freeciv-gtk2 and utility freeciv-mp-gtk2. Depends on port gtk2.

@qt5 variant

Delivers client freeciv-qt and utility freeciv-mp-qt, built with Qt5. Depends on port qt5.

@x11 variant

Delivers client freeciv-xaw. Depends on ports TBD related to X11.

@sdl2 variant

Delivers client freeciv-sdl. Depends on ports libsdl2, libsdl2_gfx, libsdl2_image, libsdl2_ttf.

@qt6 variant [future]

Delivers client freeciv-qt and utility freeciv-mp-qt, built with Qt6. Depends on future port qt6. N.B. this is a future enhancement. MacPorts appears to have no Qt6 port yet. The Qt6 support in upstream Freeciv is still experimental, and seems unlikely to be backported to their 2.6.x branch.

With no variants, the freeciv base port will not include a client, so one can host games, but not play them. I could make one variant a default, if the user doesn't specify any. Or, I could use pre-configure code to require at least one of the variants, so that the port always delivers at least one GUI client app for playing games.

Deprecations: Some of these clients, and thus the variants, may disappear over time. The ​Freeciv project roadmap calls for dropping clients as follows:

sdl client

drop in version 3.0.x. But, it looks to me like it was dropped prior to version 2.6.4. The present freeciv portfile selects the sdl client over the sdl2 client for (${os.major} <= 10), but upstream no longer supplies this client. Macports users on this OS cannot use freeciv, I guess.

xaw client

drop in version 3.0.x.

gtk2 apps

drop in version 3.1.x.

Advantage of new port

This structure lets Macports users get the most usable clients from upstream, freeciv-qt and freeciv-gtk3.22.

I hope to make the new port's long_description clearer about what is installed, thus addressing #62793, port info doesn't explain the list of executable programs.

Issues

I'm concerned that this change will surprise present users of the freeciv[-x11] ports. They will need to specify variants which weren't necessary before. The port freeciv-x11 goes away. What is the right way to announce this proposal, and gather feedback?

What is a good way of determining the exact list of ports on which each of these clients depends? I know they all build on my system, with its 2000+ ports. But I don't see an easy way to determine the minimal set of ports required.

[jmroot (Joshua Root)]

This looks reasonable in general.

Replying to JDLH:

With no variants, the freeciv base port will not include a client, so one can host games, but not play them. I could make one variant a default, if the user doesn't specify any. Or, I could use pre-configure code to require at least one of the variants, so that the port always delivers at least one GUI client app for playing games.

The GUIs should be provided as subports, not variants. Dependencies between the subports could be handled a few different ways, GUIs depending on base or base depending on a GUI, but I think the best way would be:

• freeciv is a stub port (installs as close to no files as MacPorts allows), and depends on freeciv-base.
• freeciv has a variant for each GUI, which adds a dependency on one of the GUI subports. One is on by default.
• Each of the GUI subports, like freeciv-gtk3, depends on freeciv-base.

That way, a user gets a fully-functional GUI installation whether they run port install freeciv or install one of the GUI subports directly, and the other GUIs are relatively easy to discover from port info freeciv.

sdl client

drop in version 3.0.x. But, it looks to me like it was dropped prior to version 2.6.4. The present freeciv portfile selects the sdl client over the sdl2 client for (${os.major} <= 10), but upstream no longer supplies this client. Macports users on this OS cannot use freeciv, I guess.

The release notes seem to imply that SDL1 support is still available in 2.6.x. But the freeciv port seems to be failing to build on many older OS versions, including quite a few that use SDL2, so that would probably need to be fixed to clear this up.

This structure lets Macports users get the most usable clients from upstream, freeciv-qt and freeciv-gtk3.22.

The downside of those GUIs is of course more dependencies. But making them available is definitely good.

I'm concerned that this change will surprise present users of the freeciv[-x11] ports. They will need to specify variants which weren't necessary before. The port freeciv-x11 goes away. What is the right way to announce this proposal, and gather feedback?

You would keep freeciv-x11 around as a stub port that sets replaced_by freeciv-gtk2, for at least a year.

What is a good way of determining the exact list of ports on which each of these clients depends? I know they all build on my system, with its 2000+ ports. But I don't see an easy way to determine the minimal set of ports required.

You could build with -t (trace mode) and see what breaks and what files are hidden.

[JDLH (Jim DeLaHunt)]

Thank you for the suggestions. Next I need to read the sections of the MacPorts Guide about Portfiles. This will be my first time developing a Portfile.

[JDLH (Jim DeLaHunt)]

FYI, I am working on a big revision to freeciv along these lines. I am debugging the subports one by one. Making progress. Not done.

[JDLH (Jim DeLaHunt)]

Upstream released freeciv version 2.6.6 on 2021-12-10. Source: ​https://freeciv.fandom.com/wiki/NEWS-2.6.6 . I am changing my big revision to target this version. That means my new port will jump from current 2.6.4 to 2.6.6.

[JDLH (Jim DeLaHunt)]

I will be brave and claim ownership of this ticket. Also, mark MacPorts version as 2.7.1 (not that it is relevant).

[barracuda156]

Is there no Qt4 backend? From limited experience Qt4 works far better than GTK.