Guys,
I've been giving some thought to what needs doing to get dynclasses
working on Windows. I'm not particularly intimate with Windows, but use
cygwin quite a bit.
One area that I'm still not 100% clear about is the visibility of
symbols within DLLs and executables, so please be kind!
From previous posts, you may have seen a kludgey solution to getting
dynclasses working on cygwin. The basic scheme is:
* Build a libparrot.dll, which includes an appropriate *_config.o
* Build dynclasses which link against libparrot.dll
* Build parrot.exe against libparrot.dll
[My understanding is that] DLLs cannot have unresolved symbols, or at
least they must be linked against another DLL which can provide them.
Hence, dynclasses need to be linked against libparrot.dll at compile
time, and *_config.o files need to reside in the DLL.
What we do currently linking with the parrot executable against
*_config.o files isn't satisfactory on Windows.
Does that seem reasonable so far?
Now to the bit which causes problems. Because libparrot.dll is tightly
bound to the configuration (e.g. parrot_config.o) you might potentially
need three DLLs (for miniparrot, parrot and installed parrot), which is
horrible.
What I'd like like to propose is that the information in parrot_config.o
and install_config.o be selected by the caller, either through a (DLL)
global or an argument to parrot_get_config_string. That way,
libparrot.dll can be built against it, and its personally determined by
the harness (which is compiled with -DINSTALL or such-like).
To summarise, one recipe might be:
* Build libminiparrot.dll, which includes null_config.o
* Build miniparrot, linking against libminiparrot.dll
* Create parrot_config.o and install_config.o using miniparrot
* Build libparrot.dll with parrot_config.o and install_config.o
* Build parrot, linking against libparrot.dll
* Build dynclasses, linking against libparrot.dll
* Subsequently build installed_parrot, but get it to select the
install config
There are obviously variants upon this theme, particularly where naming
is concerned, but what I wanted to get across is what links against
what, and what to do about the *_config.o files. Obviously miniparrot
could be build using an archive library etc.
Be kind on me if I've misunderstood Windows-land!
Cheers,
Nick