On Thu, 13 May 2004 10:00:53 -0400 (EDT), Andrew Dougherty wrote: > You might want to review the patch I submitted about a year and a half ago > -- it's # 18319, and it included some (but certainly not all) of your good > ideas.
Thanks, I'll do that. > I gather parrot's now trying to include stuff compiled with C++, so you'll > also need a macro for that. Furhter, if parrot's going to include stuff > compiled with C++, the "Linker" will have to be a command that correctly > handles C and C++. On Unix systems, that's probably just the C++ > compiler. I don't know what it is on Windows or VMS. IMHO, we are currently talking C only, so that shouldn't be a problem. I hope anybody tells me if I'm wrong. Still, I am curious. Why would the linker need to know about C or C++? (just didn't manage to take a grip on that thought) >> The name of the parrot library should blend into the current system (and >> might even be different for debug builds, eg libparrot_g.so (is that >> correct?) or parrotd.lib). > > For perl5, the direction we went with this issue was to embed the > different build information into the directory, rather than into the > library name. That way, you don't have to change all the command lines [...] Good enough for me. I'd say we stick with the regular names.
