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