Minimize tools-only build #13282
Minimize tools-only build #13282
Conversation
|
What is a real necessary to build just tools? Does adding all this "if not" conditions worth it? |
Avoid unnecessary work and dependencies when building tools and no
emulator.
* makefile: Skip compressing layouts and converting translations if the
emulator isn't being built.
* scripts/src/3rdparty.lua: Make libraries not needed by tools
conditional on the 'with-emulator' genie option.
* scripts/src/osd/modules.lua: Refactor module file inclusion to
optionally omit implementations other than 'none', as tools don't
depend on modules.
* scripts/src/{cpu,devices}.lua: Refactor CPU core file inclusion to
collect these similarly to the disassembler files and only build the
'optional' project including them if the emulator is being built.
* Make 'qtdbg' projects conditional on USE_QTDEBUG to avoid warnings
when Qt libraries aren't present, as tools don't need them.
skrinakron
force-pushed
the
tools-only-minim
branch
from
e4b7110 to
4f87ad9
Compare
|
Building only the tools and not the emulator was enabled in d5340b8; this PR would just skip more emulator-specific things not considered in that change. My current use case for this kind of build is to get chdman for use with MiSTer, where I have no need for MAME itself. |
|
Yes, it is very helpful for people who need to quickly build mame tool and test it. |
| function modulefiles(filepaths) | ||
| for _, filepath in ipairs(filepaths) do | ||
| if _OPTIONS["NO_MODULE_IMPLS"]~="1" or | ||
| (filepath:find("none%.cpp$") or | ||
| filepath:find("_module%.h$") or | ||
| filepath:find("/lib/[^/]+$") or | ||
| filepath:find("/monitor/[^/]+$")) then | ||
| files { | ||
| filepath | ||
| } | ||
| end | ||
| end | ||
| end |
There was a problem hiding this comment.
It seemed this small localized bit of grossness was better than either of the alternatives I contemplated:
- Defining
NO_MODULE_IMPLSfor the preprocessor and ifdefing things out at the source code level (like
is done with e.g.NO_USE_MIDI). This would smear all over the OSD module sources something that feels
more like a build-level thing, namely which modules to enable for a specific target. - Using
ifblocks or a separatefilesfunction for module files to include only for the emulator,
based on thewith-emulatorGenie option. This would separate the otherwise neatly bundled module file
lines and require you to know which blocks to place new modules as they are added.
On further reflection the if route of alternative 2 may be cleaner after all. Would that be more appealing?
There was a problem hiding this comment.
Won’t nothing depend on liboptional.a if the emulator isn’t being built anyway?
There was a problem hiding this comment.
Indeed, without the emulator liboptional isn't needed, but currently it still gets built anyway. Also due to how the CPUS["I386"] block is positioned (after the corresponding opt_tool lines rather than before like with every other CPU), the athlon and i386 CPUs are always built when TOOLS=1, which in turn requires the otherwise unnecessary SoftFloat; flipping the order to eliminate these CPUs causes linker errors for liboptional, which appears to mean some CPU must be built for liboptional to work out. This is where I gave up and went for the more drastic solution of eliminating liboptional.
It would of course be ideal if projects simply were only built if something depends on them – that might also eliminate the conditionals I added in 3rdparty.lua –, but in my (admittedly limited) spelunkings I didn't find how to do this. Is there a way?
Currently building with
EMULATOR=0andTOOLS=1entails processing layouts and translations, building libraries like BGFX and SoftFloat and dependencies like SDL_ttf, none of which appear to be necessary to build only the tools. The changes proposed here would omit the extra dependencies and avoid the unnecessary load in tools-only builds (without affecting emulator builds), leaving formats, netlists and disassemblers as the only really time-consuming parts. As an additional benefit this would make the tools much easier to package separately from the emulator for source-based Linux distributions like Gentoo.