Re: Request for comments: CONS specification

[Steven Knight]

> > SCons would be a good source of ideas for any attempt to redo or
> > revive Perl Cons
> 
> Indeed. There's a lot of good ideas in the design documents... Except
> using Python! ;-)

:-)

> > SCons handles this by actually looking in the aux file for the "ReRun"
> > message that indicates you should try to build it again.
> 
> I didn't find design documents on the TeX frontend for SCons. Do you
> have some? (if not, I'm sure I'll find TeX lovers willing to help us
> develop a build system for it...)

No, unfortunately, the design documents are out of date.  The TeX support
was added much later than when those were written.

The TeX support is pretty straightforward, actually.   The tool just
scans the .aux file for the appropriate string and re-executes TeX if
it finds it.  You can find the code in SCons/Tool/tex.py (provided you
don't mind actually *looking* at Python too much)... :-)

> > In general, being explicit about the source file is a lot less
> > problematic than guessing it.
> 
> First of all, don't forget guessing will always be an /option/. If
> something goes wrong with it, or when the situation makes it impossible,
> you just go back to the ye olde method of giving explicit information.

Well, I have to confess I actually *was* going to try to do something
similar in SCons, by supporting a Builder object that would just say
"make this":

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

(You can still find mention of this in the old design docs.)

The explicit analogs to the above would be:

        env.Program('foo.c')
        env.DVI('bar.tex')
        env.SharedLibrary('baz.c')

Pretty similar, no?

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.
You save a little bit of typing and get to use the same function/object
to build multiple types of target files, but is that really so crucial?
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).

That said, YMMV.  If this is a particular scratch you want to itch,
there's certainly no reason you can't.

> Cons should also be able to warn the user when something could be
> ambiguous in the Construct.

So when a users says "build from lexer.l", are you going to warn because
it's ambiguous whether they want the .c, .o or the .exe?

Of course you won't, because building a program is the "normal" case.
But if the normal case is building a program, why not just say that?

> > The API design will require that the user will provide (in the minimal
> > case) two pieces of information:  the type of target to build
> > (program, object file, HTML file, etc.), and one file name.
> 
> I don't agree. When I want to build foo.dvi, it's trivial to understand
> the file type. With libfoo.so too. There's a lot of cases where giving
> more than the filename is already giving too much information.

Fair enough.  It's only software, so you *can* put in as much code
as you want to make it guess things the way you want.

> > In the second case, you're forcing the build tool to guess the source
> > file name from the target name, and guessing introduces the
> > possibility of guessing *wrong*, which means you need a way to
> > disambiguate by allowing them to specify the source file name
> > anyway...
> 
> Oh yes, it seemed to me evident that guessing could not be the only way
> to deal with dependencies. The user will always be able to add
> information, everywhere Cons could try to fetch it on its own.

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.
Hence I'm leary about putting in "guesswork" where there isn't a
compelling reason for it.  Of course, opinions will differ about what
is or isn't "compelling..."

        --SK