Problem 2: A tale of two binaries

Another problem with the approach detailed in this section is that it generates a fair amount of binary code, because much of the Eiffel code is duplicated twice: once in the shared module eiffel_gluemodule.so, and once in the program proper. There are ways around this, but they seriously interfere with automated creation of targets via make--and, more than likely, the extra space will not be a tremendous concern, since code space is generally overwhelmed by heap usage in many large applications.

Still, the approach causes problems--you absolutely must ensure that the shared module and application are generated from the same code base, or features called through Eiffel may have different effects than the "same" features called through Python--obviously not the correct result!

There is a different solution, simpler in many ways, detailed in the next chapter on "Scripting Eiffel with Python", which produces only a single binary, which treats the problem slightly differently--instead of embedding Python in Eiffel with callbacks, we embed the entire Eiffel application in a custom Python interpreter. For now, though, let's see what we've accomplished with the eiffel_from_python sample application.