Opened 3 years ago

Last modified 16 months ago

#62984 assigned enhancement

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

Reported by: JDLH (Jim DeLaHunt) Owned by: JDLH (Jim DeLaHunt)
Priority: Normal Milestone:
Component: ports Version: 2.7.1
Keywords: Cc: evanmiller (Evan Miller), ShadSterling (Shad Sterling)
Port: freeciv

Description

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.

Change History (11)

comment:1 Changed 3 years ago by mascguy (Christopher Nielsen)

Cc: mascguy added

comment:2 in reply to:  description Changed 3 years ago by 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.

comment:3 Changed 3 years ago by jmroot (Joshua Root)

Port: freeciv added
Type: defectenhancement

comment:4 Changed 3 years ago by 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.

comment:5 Changed 3 years ago by 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.

comment:6 Changed 3 years ago by mascguy (Christopher Nielsen)

Cc: mascguy removed

comment:7 Changed 3 years ago by 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.

comment:8 Changed 3 years ago by JDLH (Jim DeLaHunt)

Owner: set to JDLH
Status: newassigned
Version: 2.7.1

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

comment:9 Changed 3 years ago by evanmiller (Evan Miller)

Cc: evanmiller added

comment:10 Changed 2 years ago by ShadSterling (Shad Sterling)

Cc: ShadSterling added

comment:11 Changed 16 months ago by barracuda156

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

Note: See TracTickets for help on using tickets.