Closed ajrhacker closed 1 year ago
In general, having more RAM and/or an SSD helps greatly with this sort of thing. I have 8 GB and the factory SSD in my mid-2013 MacBook Air and no files in MAME take any serious amount of time to compile.
Those specifications are close to what I've been using. I haven't actually noticed clang choking on those source files lately, but I'm sure that the problem has the potential to recur.
This has been a problem on Travis CI (and is a reason why we're not using it at this time). Though link time has been a bigger issue there.
I suggested to Micko to use Semaphore CI for now, at least until Travis CI isn't able to compile the full MAME.
https://semaphoreci.com/dankan1890/mame/branches/master/builds/60
@dankan1890 Nice, they support cache too. I'll look into setting it up.
Having been bitten by this bug again recently, I think it's being triggered by my various attempts to introduce alias templates into the core. clang still does manage to compile saturn.cpp, though it takes several minutes to do so; other drivers and devices also seem to take somewhat longer to compile (perhaps two or three times, though still only a few seconds each).
This doesn’t seem to be an issue on mainline now.
A problem that I have repeatedly experience when tinkering with MAME is that certain source files can take an incredibly long time for clang to process (7.0.2, OS X Yosemite). This only starts happening sometimes, and has been triggered by only distantly related source modifications. The usual offenders include mame/drivers/saturn.cpp, mame/drivers/apc.cpp and mame/machine/pc9801_kbd.cpp. What these files all seem to have in common is their very heavy usage of PORT_CHANGED_MEMBER. The sort of workarounds used in emu/inpttype.h seem to be completely ineffective here, perhaps due to the loads of macro expansion in general.