GTK initialization during espeakedit --compile breaks build on headless systems.

[ozzyjohnson]

Building on a remote server fails when espeakedit --compile is run with the following errors.

CXXLD  src/espeakedit
ESPEAK_DATA_PATH=/tmp/espeak src/espeakedit --compile && touch phsource/phonemes.stamp
17:23:13: Error: Unable to initialize GTK+, is DISPLAY set properly?
make[1]: *** [phsource/phonemes.stamp] Error 255
make[1]: Leaving directory `/tmp/espeak'
make: *** [all] Error 2

It looks like this issue has been around for a quite a while:

• eSpeak - PPC architecture
• #89 espeakedit --compile should not initialize wxGTK

The first link in particular gives me the notion that this is something that won't be fixed, but I figure resurfacing can't hurt and I have a workaround to share.

I've managed to get around this limitation with Xvfb (apt-get install xvfb) as a dummy display.

   export DISPLAY=:100.0
   Xvfb :100 > /dev/null 2>&1

With this in place compilation completes without issue.

For context, I'm employing this in the Dockerfile here:

• docker-tts/Dockerfile
• docker-tts - Automated Build

[rhdunn]

The espeakedit program is used by espeak to compile the phoneme and intonation voice data. The issue is that espeakedit is a GUI program written in wxWidgets. Also, from a distribution perspective, Jonathan keeps espeak separate from espeakedit in the ZIP files he publishes.

As such, this is a design flaw in the way espeak is architected. The code for compiling the phoneme and intonation files is mixed with wxWidgets code. Addressing that here would deviate the code too much and be near impossible to maintain with the current state of the codebase.

You will need to request this to be addressed by Jonathan on the main espeak-users mailing list. I doubt it will get any traction though, as it is a complex process to build the upstream espeak on the command line (you cannot build the intonation files or MBROLA voices from the command line) -- which is where this fork originated and is focused.