Support for traversing directories in use statements

[GoogleCodeExporter]

Use statements only support including files in the same directory. For large 
Umple projects (such as the Umple compiler itself) this flat directory 
structure can become hard to navigate. Either the individual files become too 
large, or there are too many files to look at.

This would allow us to the cruise.umple/src/ files into subdirectories for 
easier understanding and navigation.

This also allows other Umple projects to better organize their code.

The most simple implementation of this is to augment the grammar to support 
directory navigation (., .., / characters) in file names.

Something for discussion is whether use statements in a different directory 
that the file the compiler is invoked on should be relative to that directory 
or the root directory. However, this forces the parser to keep track of the 
directory it is currently including files from. For example:

Master.ump includes parser/UmpleInternalParser.ump

One of the following should be supported (in parser/UmpleInternalParser.ump)

use parser/UmpleInternalParser_Code.ump
use UmpleInternalParser.ump

I believe supporting the second gives more intuitive behavior. Note that the 
first is easier to implement, and after implementing the first the second is a 
non-backwards-compatible change.

Original issue reported on code.google.com by Astronomix@gmail.com on 12 May 2014 at 6:42

[GoogleCodeExporter]

Original comment by TimothyCLethbridge on 12 May 2014 at 5:42

• Added labels: Priority-High, Diffic-Easy

[GoogleCodeExporter]

I misunderstood the existing functionality. It is possible to include files in 
directories, but the working directory never changes. I'll work on that.

Original comment by Astronomix@gmail.com on 12 May 2014 at 6:28

[GoogleCodeExporter]

Since "include relative to file in command line" is the current behavior, and 
it does support including files in subdirectories, I think it better to not 
change anything. Sorry for the confusion.

Original comment by Astronomix@gmail.com on 17 May 2014 at 9:56

• Changed state: Invalid