Re: [Guidolib-devel] Code reorganization

[J. S. A. <js...@sh...>]

On Fri, 2004-01-23 at 02:10, Dominique Fober wrote:
> Scott, we apologize for the trouble! We should 
> be more rigorous in making changes that may affect cross-platform 
> development: these changes should be discussed on this list prior to be 
> made. We'll keep it in mind for the future.

That's ok... I actually have a few questions about cross-platform files.

I was doing a bit more testing with the Linux library, and discovered
some problems with the shared library and some unresolved symbols (the
static library works fine because it doesn't require all symbols to be
resolved):

/usr/local/lib/libguidoengine.so: undefined reference to
`gd_getTagArgFloat(int)'
/usr/local/lib/libguidoengine.so: undefined reference to
`gd_getTagArgName(int)'
/usr/local/lib/libguidoengine.so: undefined reference to
`gd_getTagArgType(int)'
/usr/local/lib/libguidoengine.so: undefined reference to
`GuidoCheckForFont(char const*)'
/usr/local/lib/libguidoengine.so: undefined reference to
`CreateDefaultGDevice()'
/usr/local/lib/libguidoengine.so: undefined reference to
`gd_getTagArgInt(int)'
/usr/local/lib/libguidoengine.so: undefined reference to
`gd_getTagArgUnit(int)'
/usr/local/lib/libguidoengine.so: undefined reference to
`gd_getTagArgStr(int)'

I've traced these, and the gd_* functions are referenced in the guido.h
header file (in the parser directory), but are actually defined in the
Gmn2MidiParser.cpp file (in the lib-guido2midi directory).  And the
GuidoCheckForFont and CreateDefaultGDevice are referenced in the
GUIDOEngine.h header file (prior to a platform dependent comment!) and
both are defined in GUIDOMainCarbon.cpp and GUIDOMainWin32.cpp
(depending on platform).  Finally, the include nview.h contains
application specific data as well.  It would seem that these
dependencies need to be removed in order to maintain a truly platform
dependent and modular score engine.  Perhaps we can discuss some
strategies?

This also moves towards the next task that Holger, Keith and I will be
working on - the finalization of a GGS spec, and a move to making that
the only graphic output of the score engine.  It appears now that the
noteviewer application (through the above mentioned nview.h) is
assembling the various GGS strings by way of the AddGGSOutput method. 
My thinking is that a new class be written to implement the GGS API
(when it is finalized), and that it's public API be added to the
GUIDOEngine.h header, which will be the only public header file
necessary to work with the library.  Everyone, please let me know what
your thoughts are on this.  I'll then firm things up with Holger and see
where to go next.  Thanks.

Cheers,

Scott

PS I have improved some of the linux files, and added a few
configuration scripts and an m4 macro to make things easier for other
developers who are using the auto* tools and want to support the engine
library.  The SourceForge developer cvs seems to be down for the
weekend, so I'll have to wait to commit these and account for the files
that got moved.