On 4/12/07, Ron Blaschke <[EMAIL PROTECTED]> wrote:
>> - # If we are building shared, need to include dynamic
>> libparrot.lib, otherwise
>> +
>> + # If we are building shared, need to include dynamic
>> parrot.lib, otherwise
>> # the static libparrot.lib.
> this code section and this comment in particular interests me. it
> shows me that the name of the dynamic lib is different than the static
> lib. this reminds me of some time ago when static/dynamic builds of
> parrot were overhauled, allowing either type to be built. i always
> wondered if we could build *both*. do you think this patch gets us
> closer to building both static and dynamic parrot in the same build?
The patch doesn't change that. Previously, the static library was built
at F<blib/lib/libparrot.lib>, the import library at F<libparrot.lib> (no
blib/lib here!). Now it's F<blib/lib/libparrot.lib> and
F<blib/lib/parrot.lib>, respectively.
11.04.2007 20:58 19.226.530 libparrot.lib
11.04.2007 19:43 2.685.438 parrot.lib
Both libraries get built during make, but I'm not sure if libparrot is
usable. Are we talking about a statically linked parrot.exe? I can
look into this if you like.
yes, static linking of parrot.exe. debugging is much easier with
static parrot, embedding easier with dynamic parrot. it'd be nice to
have the best of both worlds--i won't get into debugging embedded
parrot, that's *supposed* to be difficult ;-)
~jerry
