On 16/08/02 20:52 +0100, Nicholas Clark wrote: > On Thu, Aug 15, 2002 at 04:35:33PM +1000, Ken Williams wrote: > > (From a thread on the [EMAIL PROTECTED] list, turning into an > > Inline thread) > > > That seems to work fine for the C executable. So I figured I'd > > try the same technique in Inline, but no go: > > > > use Inline C => 'DATA' => > > LIBS => '-framework Carbon'; > > > > That gives me essentially the same error you got. > > > > I looked in the 'out.make' file generated by Inline, and it > > turns out that the "-framework Carbon" chunk isn't in the > > compilation command at all. I've had this problem before, with > > LIBS stuff getting dropped by Inline, but I'm not sure how to > > fix it. > > If I remember correctly, it's actually MakeMaker silently dropping anything > it doesn't think is a library from the LIBS line. So it's not actually > Inline at fault. If this is the correct cause, I'm still not sure if it > helps, as I don't know of a workaround.
Perhaps it's time to make Inline be a little more aggressive here. Since Inline is in control, it could fix up the Makefile. It already does this for some overzealous BSD security patches to MakeMaker. Extending this thought, I may want to skip the MakeMaker process altogether and simply invoke the compiler directly. Since Inline uses MakeMaker in a fixed fashion, this might be worth it, at least in the general case. I think that most of the "compile time" that Inline users experience is from MakeMaker setup. On the other hand, the beauty of Inline is that it has always just automated the safest build scenario. It inherits both the robustness and the inadequacies of the tools it glues together. On the other hand, perhaps it's time for some optimizations. Cheers, Brian > > Nicholas Clark > -- > Even better than the real thing: http://nms-cgi.sourceforge.net/
