Mapping from source to compiler output

[cpurdy]

As you can see in the introduction documentation https://github.com/xtclang/xvm/wiki/lang-module, there's an expected form of how a module is laid out, both in terms of directory names and file names.

However, there is another form, which is when the entire module fits into a single file, such as we use for our tests. Cliff said/asked "here's an ugly (to my eye) usability issue. Compiling manualTests/src/main/x/annos.x produces a module TestAnnotations.xtc output. i.e., the input file is named annos.x, the output file is named TestAnnotations.xtc and not annos.xtc. This makes the build process look confusing as hell. Just spent 30mins trying to figure out where my output files were going. If you're trying to be Java-programmer-friendly, I think we need to take a look at how this is supposed to work."

There's no argument that there is some magic "absolutely right answer" here. But there are certainly degrees of wrongness. Cliff has pointed out one such aspect. The question is: Should annos.x be compiled to annos.xtc based on the file name, instead of to TestAnnotations.xtc based on the declared module name? Personally, I'm fine either way, and I'd probably prefer what Cliff is suggesting.

The idea was that the compiled form of the module would have the module name as its file name. This is not a stupid idea, but it's primarily important within the context of a managed repository of many modules, and in such a case one would expect the file name to be the fully qualified module name, not just the short name -- since with any luck, there will be millions of Utils.xtc modules with different fully qualified names (Utils.cisco.com vs Utils.cvs.com etc.)

The other topics that tightly correlate to this conversation are the usability of the command line tools, which we've previously discussed. Primarily xtc (compile) and xec (execute). Cliff (I think? or maybe Marcus?) had previously suggested making xtc into an uber-everything command, capable of doing all Ecstasy related things (compile, run, etc.), similar to e.g. the git or the brew command. This seems reasonable to me; we could retain an xcc (suggestions welcome) explicitly for the compiler, but outside of compile and run, I don't think we need any command line tools other than The One Tool To Bind Them All (tm).

[cliffclick]

re file names: Figured we'd declare error if the file-name and internal class name weren't related. But I suppose not required. I defineatly expect the compiler XCC's input & output file names to be correlated. Near as I can tell this correlation is near uniform across build tools; you can easily exception it, but then your build tool ends up naming both the input & output files explicitly, instead of just turning the .x extension into a .xtc extension.

re: One Tool
i could split my current XEC out from the existing tools, I basically have 1 or 2 enums as my only dependencies. Not super excited about this right now, but could be talked into it. I do not find the git-One-Tool approach helpful unless we really need >3 tools.