[Freeciv-tickets] [freeciv] #48675: specenum generator

アーカイブの一覧に戻る
OSDN Ticket System norep****@osdn*****
Thu Sep 21 23:03:34 JST 2023


#48675: specenum generator

  Open Date: 2023-09-19 14:02
Last Update: 2023-09-21 16:03

URL for this Ticket:
    https://osdn.net//projects/freeciv/ticket/48675
RSS feed for this Ticket:
    https://osdn.net/ticket/ticket_rss.php?group_id=12505&tid=48675

---------------------------------------------------------------------

Last Changes/Comment on this Ticket:
2023-09-21 16:03 Updated by: alienvalkyrie

Comment:

Reply To cazfi
These might live under gen_headers, or in their own subdirectory within it. It's the directory autotools build process first, so the results are available for the rest of the build.
Good shout. Moving old generate_specenum.py there as well might be sensible too, but not worth doing now if we're planning on eventually folding it into this new script. The individual def files should probably stay with the header that's going to be including them tho.
meson.build currently lists only source files to compile. For *compilation* to work, it does not need to know regular headers. It would need to know list of these headers to generate.
That makes me think it would be best if the build system executes the new script once for each generated file, which also means there should be a one-to-one correspondence between input and output files (so not a "three big definition files" situation). One big input file making multiple output files would mean the definition already has to specify what goes where, so passing the output paths to the script would be redundant, at best a control mechanism; a checklist of "the definition should specify something for each of these files, and should specify no other output files". 
The other alternative would be calling it with multiple input files to aggregate into one output file, which could in principle also be reasonable, but in practice here would be the opposite of useful.
I don't think separate definition files for each enum make much sense. It'd mean repeating the name in multiple places (def file name, inside the def, possibly output file name); if we want to rename an enum, we'd have to rename the file, including in version control and build systems; same if we want to add or remove one. Just adds a lot of hassle, especially for potential new contributors who understand code, but are unfamiliar with the stuff around it (e.g. myself ten years ago). By extension, this means I'd go with one def per current header (potentially containing multiple enum definitions), which gets processed into one generated header file (containing all those enum definitions). We will lose the ability to define different enums in different places within the same header.
For naming, I'd generally go foo_enums.def into foo_enums_gen.h for the enums currently in foo.h. Not sure about the couple enums that are defined in .c and .cpp files, but that's a future concern.
Initial step (first subticket) should be possible without build system integration - expect developer to run the script manually, and keep the resulting header under version control. Shouldn't do that for a large number of generated headers, but just for the first.
Sounds reasonable. I take it you'd have this be the metaticket, rather than the ticket for the first step?
Also I consider #44767 (bumping Python version) a blocker for this 'cause of useful new Python features (variable annotations and f-strings).

---------------------------------------------------------------------
Ticket Status:

      Reporter: cazfi
         Owner: (None)
          Type: Patches
        Status: Open
      Priority: 5 - Medium
     MileStone: (None)
     Component: Bootstrap
      Severity: 5 - Medium
    Resolution: None
---------------------------------------------------------------------

Ticket details:

Adjusting specenum values can take a lot of effort, and that need for effort is often multiplied by the number of branches to backport the patch as the big change is unlikely to apply cleanly. The main problem is that we have to number the entries in the sources. So adding or removing entries necessitate changing all the entries that follow.
We could have just spec files describing the enum:
...
VAL_FOO, "foo name"
VAL_BAR, "bar name"
...
and a python source generator script producing a C header with the specenum definitions like they now are maintained by hand.


-- 
Ticket information of Freeciv project
Freeciv Project is hosted on OSDN

Project URL: https://osdn.net/projects/freeciv/
OSDN: https://osdn.net

URL for this Ticket:
    https://osdn.net/projects/freeciv/ticket/48675
RSS feed for this Ticket:
    https://osdn.net/ticket/ticket_rss.php?group_id=12505&tid=48675



More information about the Freeciv-tickets mailing list
アーカイブの一覧に戻る