[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CONS specs update?
From: |
H. S. Teoh |
Subject: |
Re: CONS specs update? |
Date: |
Thu, 24 Jun 2004 13:26:13 -0700 |
User-agent: |
Mutt/1.5.6+20040523i |
On Sat, Jun 19, 2004 at 08:19:29AM +0200, Pierre THIERRY wrote:
> > OK, I added a bunch of stuff to the page. :-) I'm not sure how useful
> > it is...
>
> It definitely is. I refactoring it much, to bring consistency between
> the various descriptions, and I'm thinking of some merges. I need some
> light on the following subjects:
>
> - isn't building a shared library just building an executable, as for a
> static one or for a program, being a matter of options? (this seems to
> be the case for at least GNU, Intel and Solaris C compilers)
Yes, it's a matter of options, and running 'ar' on the resulting
object files. I.e., it's another possible target that can be built
from object files. CONS, of course, can just stick with the default
target, which is an executable; however, I think it should at least
know how to build shared libraries from object files if the user
should ever ask it to.
Also, there's a difference between a shared library (.so) and a static
library (.a). You can make static libraries just by running 'ar' on
any .o files. But shared libraries require special compiler flag at
the *compile stage* to make the code relocatable, otherwise the
resulting shared library won't work.
> - is Lilypond different then any other TeX format? (in the way it is
> called, not the files it produced)
Strictly speaking, Lilypond processes the input .ly file to produce
either a .midi file or a .tex file. What the default options do is to
make it automatically run LaTeX on the resulting .tex file so that you
get a .dvi file immediately.
> - are there other parser generators than the lex and yacc families? I
> know ones for both types that target at C/C++ and ML, are there also
> other targets?
I know Java has a lexer generator ported from Flex. That would create
a .java file, possibly resulting in one or more .class files. (How
would you handle Java, btw? One .java file can be compiled into
multiple .class files depending on whether you have inner classes or
private classes defined.)
> > I wanted to add a page on custom code generators, but I wasn't sure if
> > it belonged there because it's just a broad scheme that may be used.
>
> We should assume that at any stage, the user could want to add a pre- or
> post-processor to modify a source or result file.
>
> We should provide an interface to add such processors, as the main issue
> is that some of them don't actually have a result file, but modify an
> existing one (so we can't treat them as normal steps in the build
> process).
[snip]
Ideally, though, I'd prefer to treat them as separate steps. I don't
like the idea of a file modified in-place (i.e., processingtool.pl
reads in abc.c and writes a modified version replacing abc.c).
Now about result files... one reason I added Lilypond was to bring up
the issue of how we should handle steps that produce multiple targets
in one go, e.g. Lilypond produces both a .midi and .tex file; parser
generators may produce both .c and .h files, etc.. In such cases, the
dependency graph is not a tree, but a directed (acyclic, hopefully)
graph.
T
--
"You know, maybe we don't *need* enemies." "Yeah, best friends are about all
I can take." -- Calvin & Hobbes