On Wed, 5 May 2004 13:59:14 -0400, Dan Sugalski wrote:
>>Windows requires this export list, which is currently stored in the
>>"module-definition file" libparrot.def. However, Windows provides a
>>"nicer" way of doing this, by prefixing a declaration with
>>__declspec(dllexport) someFunction
>>Windows then stores this information in the object file, and thereby
>>passing the inforation on to the linker.
>
> Yeah, options like this are available on a number of platforms. It's
> probably the right answer since it puts the declaration right with
> the function itself, but there's the issue of pulling it out, since
> we'll need to preprocess the code on most platforms.
>
> If you're up for the perl trickery needed (or, I suppose, the parrot
> trickery if you're feeling adventuresome :) we can do this. Until
> we've got something, though, I think we're going to want to stick
> with a separate file so there's only one thing to manage rather than
> two.
I guess it wouldn't be terribly hard to search for the PARROT_API
declarations, since we would know a lot about it (since we're just grepping
our own code). I had something like the following in mind (still in perl,
though, as my parrot is a little bit ...rusty), and assuming we'd write
something like
PARROT_API
Parrot_Interp Parrot_new(Parrot_Interp parent);
--snip--
my $code;
{
undef $/;
$code = <>;
}
# remove comments
$code =~ s/\/\*.*?\*\///gs;
# search for "PARROT_API ... ;" stuff
while ($code =~ /PARROT_API\s*(.*?)\s*;/gs) {
my $decl = $1;
# split into <return_type> <name> (<arguments>)
my ($rtype, $name, $args) =
$decl =~ /(\w+\W*)(\w+)\s*\((.*?)\)/;
print <<END;
Return Type: $rtype
Name: $name
Arguments: $args
END
}
--snap--
OTOH, keeping the names in a separate file doesn't seem to be that bad
either. We could still keep an empty PARROT_API macro, and use it for
documentation purpose, though. We could even use something like the above
code to check the correctness of the export file, in case someone forgot to
add ... ... well, forget the last thought. ;-)
Ron
