According to Ron Blaschke:
> - Parrot should be told during Configure to be built static
> or dynamic (shared); it should probably be dynamic on most systems
Yes.
> - The parrot library should be named C<parrot.lib> and
> C<parrot${MAJOR}${MINOR}.dll> on Windows
OK, but will Windows allow delimiter(s) on the DLL name? Without
them, there's an ambiguity (is "parrot110.dll" 1.10 or 11.0?).
Also, Parrot release numbers currently have three parts. Closer to
release you could change the Win32 DLL name to be based only on the
top two, since changes in the third number will not involve any issues
of binary compatibility[*], but at least during early development it
would be a Good Idea to include all three.
> - The dynamic parrot library C<parrot01.dll> should be in the same
> directory as C<parrot.exe>, or otherwise it must be a)explicity loaded
> or b)the directory added to the PATH environment.
OK. I haven't done much Windows software work since Win98; what's the
standard way of making a command (e.g. "parrot") available from [a]
the Win32 command line and [b] the Win32 spawn interface? The old
hack of adding PATH statements to autoexec.bat doesn't work any more.
Or so I'm told. :-)
> - Paths and/or linkage instructions should be updated accordingly, eg
> F<lib/Parrot/Test.pm>
> (my $libparrot_root = $PConfig{blib_lib_libparrot_a}) =~
> s/\$\(A\)//;
> my $libparrot_dynamic = $libparrot_root.$PConfig{share_ext};
>
> my $libparrot;
>
> # use shared library version if available
> if( -e $libparrot_dynamic ) {
> $libparrot = '-Lblib/lib -lparrot';
> } else {
> $libparrot = $libparrot_root.$PConfig{a};
> }
I think I see where you're going with this, but why test for existence
of the dll?? If a given Parrot instance included a libparrot.dll at
build time, then assume it's there; otherwise, assume it's not. The
only way these assumptions could be wrong is (1) we have a bug or (2)
the filesystem being modified in unsupported ways. I'm not interested
in papering over either of those cases.
> - There should be a macro PARROT_API, which hints the compiler how to
> link things, on platforms that support it. Eg, on Windows it should
> expand to
> '__declspec(dllexport)' if a symbol should be exported (dynamic)
> '__declspec(dllimport)' if a symbol should be imported (dynamic)
> empty string (static)
> PARROT_API must be added to each API symbol of the library.
By "added" you mean in the .h, or the .c, or both? And if both, will
the same macro with the same definition work for both places?
> - A similar macro must be present for each library, which means there
> must be a different one for dynclasses (PARROT_DYNCLASSES_API), as the
> symbols of libparrot must be imported, and the symbols of the
> dynclasses exported.
Looking at this from the point of view of a third-party PMC author,
might "PARROT_EXPORT" be closer to the relevant idea? From the
interface design perspective, does it matter whether I'm writing a
"DYNCLASS" or something else?
But then there are the fourth-party authors who want to #include the
headers that came with the third-party PMC, because they're using its
library bits or extending it. The system should support them, too,
and without inventing a new namespace ("DYNCLASSES" et al).
> - After I changed the linkage, some dynclasses failed, during access
> of C<Parrot_base_vtables[100]>. No surprise, as the array is only
> C<#define PARROT_MAX_CLASSES 100>
> long. After I changed it to 1000, the tests passed. Why gets no one
> else bitten by this? Somehow my fault? Shouldn't it be dynamically
> resized?
Absolutely. I don't want to speak for Leo, but: "Patches welcome."
> - I'm not sure where IMCC belongs. I'd guess it goes into libparrot.
> But F<imcc/main.c> goes into the parrot executable. Yet, this one
> depends on parser symbols (line, yyparse, yyin, yydebug, yylex), which
> probably should not be exported by libparrot. Any hints?
On the one hand, IMCC doesn't really help you _run_ code, so I'm not
inclined to see it part of libparrot. On the other hand, I haven't
grokked the entire code base organization, so I could be Greatly
Missing The Point.
On the gripping hand, if you'd like to experiment with putting IMCC
into libparrot, bison's "-p prefix" option seems relevant: "Rename the
external symbols used in the parser so that they start with prefix
instead of yy." Maybe "-p Parrot_imcc_"?
[*] Is there already a version number policy sketched out?
--
Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]>
Open Source is not an excuse to write fun code
then leave the actual work to others.
