From 2ade6ab94da40043186fbc2fbbf038c0f497b4e4 Mon Sep 17 00:00:00 2001 From: Grzegorz Adam Hankiewicz Date: Sun, 27 Jul 2014 22:27:21 +0200 Subject: [PATCH 1/3] Documents nimcache file naming scheme. Refs #852. --- doc/backends.txt | 60 ++++++++++++++++++++++++++++++++++++++++++++++++ doc/nimrodc.txt | 10 ++++---- 2 files changed, 66 insertions(+), 4 deletions(-) diff --git a/doc/backends.txt b/doc/backends.txt index 26576e7331..adcd741490 100644 --- a/doc/backends.txt +++ b/doc/backends.txt @@ -322,6 +322,66 @@ earlier, JavaScript doesn't require an initialisation call to ``NimMain`` or similar function and you can call the exported Nimrod proc directly. +Nimcache naming logic +--------------------- + +The `nimcache`:idx: directory is generated during compilation and will hold +either temporary or final files depending on your backend target. The default +name for the directory is ``nimcache`` but you can use the ``--nimcache`` +`compiler switch `_ to change it. + +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: + +* 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 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 `_ is always imported automatically. Same for + the `hashes module `_ 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 `_ will generate ``docutils_rstgen.c`` + because the `lib/packages/docutils directory + `_ 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 + `_ 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. + + +Nimcache and the Javascript target +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Unless you explicitly use the ``-o:filename.js`` switch as mentioned in the +previous examples, the compiler will create a ``filename.js`` file in the +``nimcache`` directory using the name of your input nimrod file. There are no +other temporary files generated, the output is always a single self contained +``.js`` file. + + Memory management ================= diff --git a/doc/nimrodc.txt b/doc/nimrodc.txt index 428c42f39d..1962eb0f0f 100644 --- a/doc/nimrodc.txt +++ b/doc/nimrodc.txt @@ -152,10 +152,12 @@ the first matching file is used. Generated C code directory -------------------------- -The generated files that Nimrod produces all go into a subdirectory called -``nimcache`` in your project directory. This makes it easy to delete all -generated files. - +The generated files that Nimrod produces all go into a subdirectory called +``nimcache`` in your project directory. This makes it easy to delete all +generated files. Files generated in this directory follow a naming logic which +you can read about in the `Nimrod Backend Integration document +`_. + However, the generated C code is not platform independent. C code generated for Linux does not compile on Windows, for instance. The comment on top of the C file lists the OS, CPU and CC the file has been compiled for. From bb34d0380a0538f2784701ed05679e31155dc232 Mon Sep 17 00:00:00 2001 From: Grzegorz Adam Hankiewicz Date: Sun, 27 Jul 2014 22:55:03 +0200 Subject: [PATCH 2/3] Makes ios example work again with new paths. Refs #852. --- .../project.pbxproj | 20 ++++++------------- .../ios/scripts/xcode_prebuild.sh | 2 +- 2 files changed, 7 insertions(+), 15 deletions(-) mode change 100644 => 100755 examples/cross_calculator/ios/scripts/xcode_prebuild.sh diff --git a/examples/cross_calculator/ios/cross-calculator.xcodeproj/project.pbxproj b/examples/cross_calculator/ios/cross-calculator.xcodeproj/project.pbxproj index 36b43d31bf..71cebc18a9 100644 --- a/examples/cross_calculator/ios/cross-calculator.xcodeproj/project.pbxproj +++ b/examples/cross_calculator/ios/cross-calculator.xcodeproj/project.pbxproj @@ -13,7 +13,7 @@ D531424D15BC87B6005EFF20 /* AppDelegate.m in Sources */ = {isa = PBXBuildFile; fileRef = D531424A15BC87B6005EFF20 /* AppDelegate.m */; }; D531424E15BC87B6005EFF20 /* main.m in Sources */ = {isa = PBXBuildFile; fileRef = D531424B15BC87B6005EFF20 /* main.m */; }; D531427215BC94B1005EFF20 /* backend.m in Sources */ = {isa = PBXBuildFile; fileRef = D531426F15BC94B1005EFF20 /* backend.m */; }; - D531427415BC94B1005EFF20 /* system.m in Sources */ = {isa = PBXBuildFile; fileRef = D531427115BC94B1005EFF20 /* system.m */; }; + D531427415BC94B1005EFF20 /* stdlib_system.m in Sources */ = {isa = PBXBuildFile; fileRef = D531427115BC94B1005EFF20 /* stdlib_system.m */; }; D5B6F94815FA8D4C0084A85B /* NRViewController.m in Sources */ = {isa = PBXBuildFile; fileRef = D5B6F94615FA8D4C0084A85B /* NRViewController.m */; }; /* End PBXBuildFile section */ @@ -30,7 +30,7 @@ D531426715BC91EF005EFF20 /* tags.sh */ = {isa = PBXFileReference; lastKnownFileType = text.script.sh; name = tags.sh; path = scripts/tags.sh; sourceTree = ""; }; D531426815BC91EF005EFF20 /* xcode_prebuild.sh */ = {isa = PBXFileReference; lastKnownFileType = text.script.sh; name = xcode_prebuild.sh; path = scripts/xcode_prebuild.sh; sourceTree = ""; }; D531426F15BC94B1005EFF20 /* backend.m */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.objc; name = backend.m; path = build/nimcache/backend.m; sourceTree = ""; }; - D531427115BC94B1005EFF20 /* system.m */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.objc; name = system.m; path = build/nimcache/system.m; sourceTree = ""; }; + D531427115BC94B1005EFF20 /* stdlib_system.m */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.objc; name = stdlib_system.m; path = build/nimcache/stdlib_system.m; sourceTree = ""; }; D592E19015C7120F005258EA /* backend.h */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; name = backend.h; path = build/nimcache/backend.h; sourceTree = ""; }; D592E19115C71415005258EA /* nimbase.h */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; name = nimbase.h; path = build/nimcache/nimbase.h; sourceTree = ""; }; D5B6F94515FA8D4C0084A85B /* NRViewController.h */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; name = NRViewController.h; path = src/NRViewController.h; sourceTree = ""; }; @@ -135,7 +135,7 @@ D592E19015C7120F005258EA /* backend.h */, D531426F15BC94B1005EFF20 /* backend.m */, D592E19115C71415005258EA /* nimbase.h */, - D531427115BC94B1005EFF20 /* system.m */, + D531427115BC94B1005EFF20 /* stdlib_system.m */, ); name = nimrod; sourceTree = ""; @@ -229,7 +229,7 @@ D531424D15BC87B6005EFF20 /* AppDelegate.m in Sources */, D531424E15BC87B6005EFF20 /* main.m in Sources */, D531427215BC94B1005EFF20 /* backend.m in Sources */, - D531427415BC94B1005EFF20 /* system.m in Sources */, + D531427415BC94B1005EFF20 /* stdlib_system.m in Sources */, D5B6F94815FA8D4C0084A85B /* NRViewController.m in Sources */, ); runOnlyForDeploymentPostprocessing = 0; @@ -259,11 +259,7 @@ GCC_WARN_ABOUT_MISSING_PROTOTYPES = YES; GCC_WARN_ABOUT_RETURN_TYPE = YES; GCC_WARN_UNUSED_VARIABLE = YES; - IPHONEOS_DEPLOYMENT_TARGET = 3.0; - OTHER_LDFLAGS = ( - "-weak_library", - /usr/lib/libSystem.B.dylib, - ); + IPHONEOS_DEPLOYMENT_TARGET = 4.3; SDKROOT = iphoneos; TARGETED_DEVICE_FAMILY = "1,2"; }; @@ -284,12 +280,8 @@ GCC_WARN_ABOUT_MISSING_PROTOTYPES = YES; GCC_WARN_ABOUT_RETURN_TYPE = YES; GCC_WARN_UNUSED_VARIABLE = YES; - IPHONEOS_DEPLOYMENT_TARGET = 3.0; + IPHONEOS_DEPLOYMENT_TARGET = 4.3; OTHER_CFLAGS = "-DNS_BLOCK_ASSERTIONS=1"; - OTHER_LDFLAGS = ( - "-weak_library", - /usr/lib/libSystem.B.dylib, - ); SDKROOT = iphoneos; TARGETED_DEVICE_FAMILY = "1,2"; VALIDATE_PRODUCT = YES; diff --git a/examples/cross_calculator/ios/scripts/xcode_prebuild.sh b/examples/cross_calculator/ios/scripts/xcode_prebuild.sh old mode 100644 new mode 100755 index c6d38f1641..90bafd74e4 --- a/examples/cross_calculator/ios/scripts/xcode_prebuild.sh +++ b/examples/cross_calculator/ios/scripts/xcode_prebuild.sh @@ -22,7 +22,7 @@ DEST_NIMBASE=build/nimcache/nimbase.h if [ -d src ] then $PATH_TO_NIMROD objc --noMain --app:lib \ - --nimcache:build/nimcache --compileOnly \ + --nimcache:./build/nimcache --compileOnly \ --header --cpu:i386 ../nimrod_backend/backend.nim if [ "${PATH_TO_NIMBASE}" -nt "${DEST_NIMBASE}" ] then From d47971b9caa928b954203633fad2ef31628bf35f Mon Sep 17 00:00:00 2001 From: Grzegorz Adam Hankiewicz Date: Thu, 31 Jul 2014 14:38:35 +0200 Subject: [PATCH 3/3] Corrects description of nimcache file naming. Refs #852. --- doc/backends.txt | 54 +++++++++++++++++++++++------------------------- 1 file changed, 26 insertions(+), 28 deletions(-) diff --git a/doc/backends.txt b/doc/backends.txt index adcd741490..c2dbb0af66 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 + `_ 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 `_ is always imported automatically. Same for the `hashes module `_ which will be named - ``stdlib_hashes.c`` + ``stdlib_hashes.c``. The ``stdlib_`` prefix comes from the *fake* + ``lib/stdlib.babel`` file. -* 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 `_ will generate ``docutils_rstgen.c`` - because the `lib/packages/docutils directory - `_ 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 - `_ 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. +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