Corrects description of nimcache file naming. Refs #852.

1 files changed, 27 insertions, 29 deletions

diff --git a/doc/backends.txt b/doc/backends.txt
index adcd74149..c2dbb0af6 100644
--- a/doc/backends.txt
+++ b/doc/backends.txt
@@ -334,42 +334,40 @@ Nimcache and C like targets
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 The C like backends will place their temporary ``.c``, ``.cpp`` or ``.m`` files
-in the ``nimcache`` directory. The name of this files follows this logic:
+in the ``nimcache`` directory. The naming of these files follows the pattern
+``babelPackageName_`` + ``nimrodSource``:
 
-* Filenames for your project will be renamed from ``.nim`` to have the
-  extension of your target backend (from now on ``.c`` for these examples), but
-  otherwise nothing else will change. This will quickly break if your project
-  consists of a main ``proj.nim`` file which includes a ``utils/proj.nim``
-  file: both ``proj.nim`` files will generate the same name ``proj.c`` output
-  in the ``nimcache`` directory overwriting themselves!
+* Filenames for modules imported from `Babel packages
+  <https://github.com/nimrod-code/babel>`_ will end up with
+  ``babelPackageName_module.c``. For example, if you import the
+  ``argument_parser`` module from the same name Babel package you
+  will end up with a ``argument_parser_argument_parser.c`` file
+  under ``nimcache``.  The name of the Babel package comes from the
+  ``proj.babel`` file, the actual contents are not read by the
+  compiler.
+
+* Filenames for non babel packages (like your project) will be
+  renamed from ``.nim`` to have the extension of your target backend
+  (from now on ``.c`` for these examples), but otherwise nothing
+  else will change. This will quickly break if your project consists
+  of a main ``proj.nim`` file which includes a ``utils/proj.nim``
+  file: both ``proj.nim`` files will generate the same name ``proj.c``
+  output in the ``nimcache`` directory overwriting themselves!
 
 * Filenames for modules found in the standard library will be named
   ``stdlib_module.c``. Unless you are doing something special, you
   will end up with at least ``stdlib_system.c``, since the `system
   module <system.html>`_ is always imported automatically. Same for
   the `hashes module <hashes.html>`_ which will be named
-  ``stdlib_hashes.c``
-
-* Filenames for modules not part of the standard library and found
-  through additional paths specified with the ``--path`` compiler
-  switch will use as prefix their parent directory. For example,
-  the `rstgen module <rstgen.html>`_ will generate ``docutils_rstgen.c``
-  because the `lib/packages/docutils directory
-  <https://github.com/Araq/Nimrod/tree/devel/lib/packages/docutils>`_ is
-  not included in the standard library and you need to either write
-  ``import packages/docutils/rstgen`` or add
-  ``--path:"$lib/pkages/docutils`` to the compiler switches to be
-  able to use it.
-
-* Filenames for modules imported from `babel packages
-  <https://github.com/nimrod-code/babel>`_ will end up with
-  ``babelPackageName_module.c``. For example, if you import the
-  ``argument_parser`` module from the same name babel package you will end up
-  with a ``argument_parser_argument_parser.c`` file under ``nimcache``.
-
-To find out about what paths are part of the default standard library, create a
-dummy ``hello.nim`` file and run ``nimrod dump hello.nim``. This will display
-the defined simbols and the list of paths for the standard library.
+  ``stdlib_hashes.c``. The ``stdlib_`` prefix comes from the *fake*
+  ``lib/stdlib.babel`` file.
+
+To find the name of a Babel package the compiler searches for a ``*.babel``
+file in the parent directory hierarchy of whatever module you are compiling.
+Even if you are in a subdirectory of your project, a parent ``*.babel`` file
+will influence the naming of the nimcache name. This means that on Unix systems
+creating the file ``~/foo.babel`` will automatically prefix all nimcache files
+not part of another package with the string ``foo_``.
 
 
 Nimcache and the Javascript target