On Fri, Aug 16, 2002 at 03:19:10PM -0700, Brian Ingerson wrote:
> On 16/08/02 20:52 +0100, Nicholas Clark wrote:

> > 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.

> 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.

Inline only uses MakeMaker to compile 1 XS file into 1 C file into 1 shared
object, doesn't it? It's not using most of MakeMaker's functionality.

Invoking the compiler in a more direct fashion would also avoid make.
So it would allow much better error diagnostics.

> 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.

Wasn't the first of those hands supposed do be "on one hand"? :-)

I don't know much about Module::Build (apart from seeming to remember that it
uses YAML), but would it make more sense to have Inline invoke Module::Build
to do its dirty work?

That feels like it avoids re-inventing the wheel, or at least re-inventing
the dirty bits that involve coercing the C compiler into compiling things.

Nicholas Clark
-- 
Even better than the real thing:        http://nms-cgi.sourceforge.net/

Reply via email to