Loading ...
Sorry, an error occurred while loading the content.

Re: importVocab and output directories

Expand Messages
  • Markus Pilzecker
    ... I d like to adopt a somehow reverted viewpoint: In the world of programming environments, we are used to a kind of working, where a file ``knows , what it
    Message 1 of 3 , Mar 1 5:47 AM
    • 0 Attachment
      Jan Mikkelsen writes:
      > From: "Jan Mikkelsen" <janm@...>
      >
      > Hi,
      >
      > 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.
      >
      I'd like to adopt a somehow reverted viewpoint:
      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,

      Markus


      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.
    • Jan Mikkelsen
      ... working, ... ``knows , ... [ proposal to implement dependency generation for antlr snipped ] I think these issues are related, but different. A C source
      Message 2 of 3 , Mar 1 5:20 PM
      • 0 Attachment
        >I'd like to adopt a somehow reverted viewpoint:
        > 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, ...
        [ proposal to implement dependency generation for antlr snipped ]

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

        Jan Mikkelsen
        janm@...
      Your message has been successfully submitted and would be delivered to recipients shortly.