mame.lst requires either validation or removal

[angelosa]

1. Adding and removing sets in source base has this catch that it isn't explicitly tested against drifts in mame.lst. A possible CI script doesn't necessarily need to compile MAME but just text search inside but, at the same time ...
2. I'm not against the removal of this file, it's at best a duplicated data liability that lives in GAME and friends rows anyway, no idea about the technical implications at current time.

[cuavas]

You can’t remove it because something needs to reference the driver structures. There’s no portable way to force the linker to include static initialisation for an object with no referenced symbols. Well, to be precise, if you removed it, you’d need to replace it with something else that references the driver structures (or something else in every source file containing driver structures), which would end up effectively being the same thing.

There already is some validation:

• If you remove or rename a driver it a source file and forget to update mame.lst, a full build will break with undefined symbols. A SOURCES= build will also fail if it includes the affected files. Everyone should at least build their changes before submission, so these issues will be caught quickly.
• The “Reconcile driver list” task in Linux CI builds catches cases where as driver is moved from one source file to another but mame.lst isn’t updated accordingly. People can do this themselves after moving drivers around (it’s just a function of scripts/build/makedep.py), but even if they don’t, it will get caught by the next CI run. Failing to update mame.lst after moving drivers between source files can also cause SOURCES= builds to fail with undefined symbols, providing another point where these errors can be caught.

The only things that aren’t caught automatically is failing to add a new driver to mame.lst, and incorrectly removing a driver from mame.lst when it hasn’t been removed from the source.

Failing to add a driver to mame.lst shouldn’t happen if people are actually testing their additions. If you build MAME (even with SOURCES=) without adding the driver to mame.lst, you won’t be able to run the new system, which people should be doing even for skeletons to ensure they don’t crash/lock up on start or something.

Inadvertently removing a driver from mame.lst doesn’t seem to be an issue in practice – I don’t recall seeing it happen. If it does, the removal will show up at release time as the script for identifying new/promoted systems also lists apparent removals.