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 Changed 3 years ago by jmroot (Joshua Root)
comment:3 Changed 3 years ago by jmroot (Joshua Root)
Port: | freeciv added |
---|---|
Type: | defect → enhancement |
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: | new → assigned |
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.
This looks reasonable in general.
Replying to JDLH:
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 onfreeciv-base
.freeciv
has a variant for each GUI, which adds a dependency on one of the GUI subports. One is on by default.freeciv-gtk3
, depends onfreeciv-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 fromport info freeciv
.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.
The downside of those GUIs is of course more dependencies. But making them available is definitely good.
You would keep
freeciv-x11
around as a stub port that setsreplaced_by freeciv-gtk2
, for at least a year.You could build with
-t
(trace mode) and see what breaks and what files are hidden.