Re: [Guidolib-devel] Code reorganization

[Dominique F. <fo...@gr...>]

Hi Scott,

Le 23 janv. 04, =E0 21:28, J. Scott Amort a =E9crit :
>
> 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).

The gd_getTagArgxxx functions problem comes from historical reasons:=20
when the
open source project started, several parsers were co-existing. The=20
parser/naguido.cpp and .h files seems to be part of the remaining=20
inconsistencies since they're only used by the gmn2midi project which=20
also declares and implements the gd_getTagArgxxx functions.
I propose to move the naguido.cpp and .h files from the parser folder=20
to the lib-guido2midi folder. A header file should also be created to=20
declare the gd_getTagArgxxx functions: Gmn2MidiParser.h.
This should solve the problem for the library. It has already been=20
tested here. We'll wait for possible objections before committing.

Concerning GuidoCheckForFont and CreateDefaultGDevice, these are=20
obsolete API and we'll remove them from the lib-score-engine files.


>  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?
>

Again, these application specific APIs (AddGGSOutput, AddGuidoOutput)=20
are here for historical reasons, apparently long before the open source=20=

project. Feel free to move them to a more adequate place.

> 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.

In the current implementation of the graphic engine, the graphic output=20=

and the GGS output are co-existing. All our current developments rely=20
on the graphic output, therefore I'm strongly in favor of maintaining=20
both, as long as they are needed. Moreover, the current abstraction=20
layer over the graphic device dependencies could perhaps be also used=20
for the GGS output; this is just an hypothesis, I don't know the GGS=20
requirements but I think the idea is worth checking.

> 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.

That's ok for me.

best
dom