Re: Request for comments: CONS specification

[Pierre THIERRY]

> You can find the code in SCons/Tool/tex.py (provided you don't mind
> actually *looking* at Python too much)... :-)

I think I will survive, so I'll give a look. I also know some true LaTeX
fanatics, so I'm pretty sure I can find help for this frontend.

>         env.Make('foo')
>         env.Make('bar.dvi')
>         env.Make('libbaz.so')

It's the way I think the user should have to do it's build most of the
time, when they are straightforward. Because I'm very vrey lazy, I think
it will be Do instead of Make (less typing ;-).

> In practice, the advantage (if there really is any) of a
> guess-what-I-want Builder is marginal enough that it's just not been
> worth implementing. [...] That said, YMMV.  If this is a particular
> scratch you want to itch, there's certainly no reason you can't.

There's something like that. But I also want to address a design goal of
SCons, with that. ;-)

When some non-hacker users will use Cons, they will not have to learn
more than typing Do and their target. When you're learning TeX, for
example (I'm learning it, I speak from experience...), it's pretty
comfortable to have this simple Construct:

        Do 'learning-doc.ps';
        Do 'learning-doc.dvi';

and just having to launch cons to rebuild your DVI, inspect it, and
relaunch cons to have the Postcript written[1].

When I write a very simple C program, here is my Makfile:

        hello: main.o hello.o

Nothing more, not much to learn about Make for it to work. I don't see
why it should be more difficult for Cons. (remember [S]Cons should be
better than Make ;-)

> You still have to support being explicit for all but the simplest
> cases, so *optimizing* the simple case really doesn't buy you as much
> as you probably think it will (IMHO).

In my understanding, the guessing could also be used in very huge
projects, in fact. I think its limits will be clearer when we will have
defined more precisely its algorithm... (and because I hope Cons will be
sufficiently modular, everyone will be free to write another guesser, or
a particular guessing model for its special purpose)

> I thought the same way about a number of places where SCons "does the
> right thing" out of the box.  In practice, we've found that people
> seem to file bug reports (or ask questions) any time the default
> behavior doesn't do what they want, even if there's a way to configure
> it explicitly.

I think we'll have to learn from that, and document this very carefully.

If you have some computer newbies next to you, keep an eye on them, they
will be needed in the beta-test of our guessing system. ;-)

Automatically,
le Moine Fou
 
[1] I just thought of an interesting optional feature: be able to call a
target by a unambiguous part of its name, like the GnupG model of naming
a key (who, in fact, don't mind receiving an ambiguous name, and take
the first match). In the case of this kind of simple Construct, the
commands to build would be 'cons dvi' and 'cons ps'...
-- 
address@hidden
OpenPGP 0xD9D50D8A

signature.asc
Description: Digital signature