On 08/10/02 10:45 +1000, Sisyphus wrote:
> 
> ----- Original Message -----
> From: "Ken Williams" <[EMAIL PROTECTED]>
> To: "Brian Ingerson" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>; "Sisyphus" <[EMAIL PROTECTED]>
> Sent: Tuesday, October 08, 2002 10:24 AM
> Subject: Re: out.make
> 
> 
> >
> > On Tuesday, October 8, 2002, at 04:17  AM, Brian Ingerson wrote:
> >
> > > On 07/10/02 18:11 +1000, Ken Williams wrote:
> > >>
> > >> On Monday, October 7, 2002, at 08:38  AM, Sisyphus wrote:
> > >>>
> > >>>>
> > >>>> It might be worth thinking about giving varying degrees of
> > >>>> the output
> > >>>> depending on command line options, or CONFIG directives.
> > >>>>
> > >>>
> > >>> Actually - now that I take the time to think about it - I
> > >>> don't see any
> > >>> problem with altering "$make > out.make 2>&1" to "$make".
> > >>
> > >> I agree.  I'd rather remove layers between me and the build process
> > >> output too.  If I want it in a file, I'd redirect it there.
> > >
> > > Well, I'm not so sure. The make file would print output on
> > > success as well as
> > > failure. I'm not willing to make that the default behaviour. Inline is
> > > suppose to be magic, like Perl. You don't get messages when Perl is
> > > compiling. I think I'll continue to write the messages to a
> > > file, but dump
> > > the file to the terminal if an error occurs.
> >
> > Oh, I just realized we may be talking about two different
> > cases.  I'm speaking mainly about the module case, and I think
> > you may be speaking mainly about the script case.  I do agree
> > that scripts shouldn't dump status/commands unless there's an
> > error.  For modules, I'd prefer for the status/commands to be
> > displayed by default, but I probably won't argue too strenuously
> > for it if there's a simple way for me to turn it on.
> >
> 
> Fwiw I still prefer having the output go to the screen, irrespective of
> whether it's a script or a module that I'm building. That's mainly a
> "convenience" consideration, for me - but I also don't see anything
> inconsistent with having it that way.
> Using Inline 'out of the box' you currently don't get to see any output of
> 'make' on the screen. For me, in every other situation that 'make' runs, I
> get to see its output on the screen. So I would argue (if I wanted to get
> picky) that the current  default behaviour of Inline (in this regard) is out
> of step with conventional practice.

Let's make it an easy option. And Inline::MakeMaker can turn it on for module
builds. Someone on P5P mentioned it was too quiet as well.

> But I don't want to get picky, and I *do* understand Brian's view of wanting
> it to run, as closely as possible, like a normal perl script.

FBOW, Inline has an expected behavior. I'd like to keep that. The "magic" is
definitely one of it's charms to new users. It's what makes them stare in
disbelief and then want to learn more about how the whole thing works. No
need to burst their bubble too quickly. ;)

> (Being able to see the output of make also helps fill in that long period
> where you're otherwise waiting for something to happen .... and wondering if
> it ever will :-)

Yes. That would (will) be true. But I also think we can do some things to
make the compile not take so darn long. With pluggable backends we'll be able
to build shared objects, without Parse::RecDescent, make, or even XS. I can
imagine cutting the time down by an order of magnitude.

One reason I do like the current, slow way of doing things, is because it's
stable and portable as heck. It's practically guaranteed to work because it
uses XS and MakeMaker which themselves are stable and portable as heck.

Cheers, Brian

Reply via email to