symbols.xml version name format

[cvuchener]

Latest versions names are:

• v0.50.08-beta-1 win64 STEAM
• v0.50.07-steam SDL win64
• v0.50.07-classic SDL win64
• v0.50.07-itch SDL win64

I need to guess the ABI from those names, but it becomes difficult if win64 is moving around. I'd like to either have a standard version name format that I can parse or add more metadata to versions elements (I need the ABI, something like abi="msvc2015_64" would help me). What would you prefer? (even with explicit ABI, it would be nice to have consistent version names)

[ab9rf]

we're still feeling our way out on these given that Bay12 keeps changing things too; 0.50.08-beta-1 reflects the the first time Bay12 has done a public beta release

the SDL element has been removed because Bay12 no longer produces non-SDL builds and does not appear likely to start doing so again in the future. i'm only leaving the win64 element because i reasonably expect Bay12 to resume producing non-windows builds in the future. that said, we do not expect there to be future win32 builds

since i'm the one doing all new-release processing at the moment, i'm just going to say that my intentions for now are to use the DF version followed by a platform identifier (so far always win64) followed by an edition identifier (so far STEAM, ITCH, or CLASSIC). this may get revised further once Bay12 starts producing Mac and Linux ports or if other editions start appearing, but since i can't predict what Bay12 will do i likewise cannot predict what will be needed to differentiate among the different editions of any particular version Bay12 publishes

[lethosor]

I renamed it so it at least follows the same pattern as symbol tables before it. Evidently I should have waited another minute :)

I'm fine with dropping the SDL component, and rearranging other components, as long as we're consistent between versions present in symbols.xml at the same time.

Out of curiosity, what do you need the ABI for? Are you developing something with the intent of targeting different compiler ABIs? I'm not sure there is a canonical name for the ABIs that DF happens to use.

[ab9rf]

i just deleted that entry from the master (stable) branch entirely because stable and 50.08-beta-1 have different alignments for world and thus the stable branch will simply not work with 50.08-beta-1 anyway. until Bay12 actually releases 50.08, the structures repo will be bifurcated between a stable branch and a beta-support branch. i believe Tarn has stated that the public beta is an 'experiment' so it's hard to predict at this point whether this is a one-off incident or a harbinger of what is to become a standard practice

[ab9rf]

an additional complication to think about: now that some dfhack team members have access to Bay12 private betas, we may need to, from time to time, produce symbols stanzas for builds of DF that aren't generally published. it is not clear how we should deal with this.

also Bay12 does not have a consistent way of naming builds. i now have, i think, six different versions of DF that are "between" 50.07 and 50.08 on my computer, some of which claim to be 50.07, and others of which claim to be 50.08b1. Tarn doesn't reliably change the version string in nonreleased private betas (and even occasionally in release builds), so we're literally making this up as we go

[cvuchener]

Out of curiosity, what do you need the ABI for? Are you developing something with the intent of targeting different compiler ABIs? I'm not sure there is a canonical name for the ABIs that DF happens to use.

I'm reading structures data from an external application. I need to know the ABI so I can know how the structures are laid out. I'm working toward uncoupling platform and ABI. For example interacting with DF running in Wine means using the Linux platform with the MSVC ABI. I don't want support only one ABI per platfrom like Dwarf Therapist currently does.

I don't think there are canonical names. Actually there are two kind of ABI I'm using: the one defining how the compiler lay out structures/classes (e.g. Itanium C++ ABI), and the standard library implementation. But I don't think they need to be separated: a std library build will imply a compiler ABI. I'm currently calling them msvc2010, msvc2015, gcc (for gcc + libstdc++) (and I guess I will soon need gcc_cxx11 or something). But I'm not attached to these names. msvc2015 could be msvc14x or whatever.

It's nothing urgent yet. But I may need rely more on this in the future. Better to react when my stupid script breaks today, than when a more widely distributed application does in the future.

[ab9rf]

my intention will be that edition identifiers for builds that are targeted to the Windows 64-bit ABI will have "win64" somewhere in their edition identifier. i can't say what will be in the edition string of any other editions because there aren't any recent DF editions that aren't Windows 64-bit. experience with past versions is not necessarily useful here; the version of gcc that was used to build the last linux builds of DF is now deprecated, and it stands to reason that Putnam (who is doing those builds, according to all reports) will almost certainly use a different compiler than was used for the last tranche, and thus may well end up being a different ABI, given that gcc's linux ABI changed about six months ago. and we have no idea what the mac builds might end up being like, for all we know they may end up doing both x64 and arm builds