Re: importVocab and output directories
- Jan Mikkelsen writes:
> From: "Jan Mikkelsen" <janm@...>I'd like to adopt a somehow reverted viewpoint:
> When using importVocab, antlr will only search for the TokenTypes file in
> the current directory. If you used -o option to antlr, importing the
> generated tokens can be a bit of a pain.
> Something like a -I option to antlr so it knows where to look for TokenTypes
> files would be really useful. I'm happy to make the changes, assuming
> they'd be accepted into the main source tree.
In the world of programming environments, we are used to a kind of working,
where a file ``knows'', what it is dependent of. E.g. a C source ``knows'',
which header files it relies upon, a Java source ``knows'', what other
class-files it is dependent of, ...
So the problem is more:
antlr, processing a certain grammar file, may well know, what this grammar
is dependent of [presumed, that this information is in the grammar at all]
and may base its decisions upon that. This is just like javac knows, what
else to compile etc.
But -- antlr will have to provide a means to publish that knowledge in order
to give other tools, e.g. make, a handle to base their decisions upon.
This is just like most cc-s have a -M option, which lets them generate a
list of dependents.
So, what I would propose, is to extend the .g-syntax by things like import
statements, in order to tell antlr, which namespace outer entities are to be
recruited from. This is relevant for vocabularies and supergrammars.
Then antlr, besides implementing the semantics for this syntax extension, has
to provide some option-controlled means to publish, from which exact namespace
it would need a certain supergrammar and from which exact namespace it would
take a certain vocabulary.
Then it would smoothly run in a make environment.
'Hope, I could have made my ideas clear,
PS: Then for those, working by hand, antlr could act upon a single source
file automatically. And it's the person in the role of the programmer,
who knows, which dependents he relies upon. The person in the role of
the software deployer, who just makes, builds and packs, has to be told,
what is related.
>I'd like to adopt a somehow reverted viewpoint:working,
> In the world of programming environments, we are used to a kind of
> where a file ``knows'', what it is dependent of. E.g. a C source``knows'',
> which header files it relies upon, a Java source ``knows'', what other[ proposal to implement dependency generation for antlr snipped ]
> class-files it is dependent of, ...
I think these issues are related, but different.
A C source file knows that it depends on an include file, for example
"#include <stdio.h>". It doesn't know where stdio.h lives, and nor should
it. It might live in a different place different machines, and that kind of
dependency shouldn't be reflected in the source code.
For something like "cc -M" to work, cc also needs to know where to go
looking for include files if they aren't all in the same directory. Without
that information, it can't generate a list of dependencies. Not to mention
not being able to compile the code.
importVocab says bring in the vocabulary with this name. At the moment,
antlr assumes that it must be in the current directory. I'd really like to
be able to tell antlr to look somewhere else.
I can also see the value of a -M option for antlr to generate dependencies,
but it is less critical. I have autogeneration of dependencies for C/C++,
and depend on it. But I have 2-3 orders of magnitude more C++ files than
antlr files, so maintaining antlr dependencies by hand is a little less