[svn ci] Changes to dynoplibs build process

I have just checked in some changes that makes the dynamic op libraries
build process work very much like the dynamic PMCs one. This has two good
consequences:

* Dynamic op libraries can (hopefully) now be built anywhere dynamic PMCs
can. Including Win32. Yay.

* More importantly, this means the dynamic ops can be used easily by
languages and projects not in the Parrot source tree, just as dynamic PMCs
can.

Comments and testing very welcome (cd src/dynoplibs && make) - we don't
build dynamic op libs as part of the normal build process, but maybe if they
build successfully in enough places we can now. Note that dynamic op libs
do not *work* on Win32 yet - I'm not sure what their status is (well, was
anyway) on other platforms. That is coming soon.

Also, if there are any volunteers to write tests for dynamic op libs, that'd
be good - we don't have any at present.

Have fun,

Jonathan

I would really like some feedback from MinGW and cygwin folks on how
dynoplibs build and work for them, as I've taken the "mark the code"
approach rather than the DEF file approach. To test, build a (clean) Parrot
and then:-

cd src\dynoplibs
make
..\..\parrot dan.pasm
..\..\parrot test.pasm

First of those should print 11, second a load of stuff ending with 42, if it
works.

Thanks,

Jonathan

Works straight off on cygwin. :-) Gives the answers you wanted.

How much info did you want about the way it builds?

[I suspect that this isn't the answer that your asking for, but it
seems to run ops2c.pl for each runcore on the dynops, and then builds
.o from each one, and then finally just builds DLLs from them (i.e.
2x4 DLLs)]

cygwin seems to be able to use both .def files or just export all the
symbols from a DLL, the latter being what is done here.

Nick

I badly phrased my question - I guess I shoulda written "if" rather than
"how". That's what happens when I write emails at 2AM. ;-)

That's what I'd expect, yep.

Good. I want to do away with the .def files for all platforms we can - it's
a pain as the main one keeps getting out of sync with the code. Knowing
cygwin can handle exporting by decorating the code helps towards that. And
I'd guess it points to MinGW handling it too as both use gcc.

Thanks for testing,

Jonathan