Re: Request for comments: CONS specification

Pierre THIERRY <[email protected]> Fri, 28 May 2004 05:34:19 +0200
Newsgroups gmane.comp.gnu.cons.general
Message-ID <[email protected]>
--===============1859558013==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="gmhhrsDozM2n+uz5"
Content-Disposition: inline


--gmhhrsDozM2n+uz5
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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

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

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

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

> I want to build a program from "lexer.l"

If the only target of lexer.l is lexer.c, for example, and without
specific instructions (e.g. I want a library), Cons should guess you
want a program. So this becomes:

	I want to build from "lexer.l"

> I want to build a program named "lexer"

The case of UNI~x program maybe cannot be simplified, because it has no
extension. But as it is the main use of a build tool, we could take the
assumption that without file extension, we have a program. On some
systems, the problem disappear (.exe files). So it becomes

	I want to build "lexer"

With a lexer.c file, and automatic dependency analysis to add the other
needed source files, this should works well.

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

Cons must be as flexible as possible. We should never force the user to
a particular way of using Cons. TIMTOWDI ;-)

Flexibly,
le Moine Fou
--=20
[email protected]
OpenPGP 0xD9D50D8A

--gmhhrsDozM2n+uz5
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAtrM6xe13INnVDYoRApPGAJ9aXbUrUrBX0emY8MO/8oYqZxk8RQCgkZAX
fP60nCQMC+nRFjJdKXob/co=
=YI1S
-----END PGP SIGNATURE-----

--gmhhrsDozM2n+uz5--



--===============1859558013==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
[email protected]
http://mail.gnu.org/mailman/listinfo/cons-discuss
Cons URL: http://www.dsmit.com/cons/
--===============1859558013==--