Unable to compile external files with same name as module.

[Angluca]

Hi, I learn it write some code.
C invocation example

I don't know why build it error, I use nim 0.11.2 at osx 10.10 (rmbp13).
Echo error:

== test.c ==
int csum(int n) {
    if(n <= 0) return 0;
    return n + csum(n - 1);
}
== test.nim ==
{.compile: "test.c".}
proc csum(n: cint): cint {.importc.}
echo csum(100)

== build info ==
nim c test.nim
[Linking]
Undefined symbols for architecture x86_64:
  "_csum", referenced from:
      _testInit in test.o
      _testInit in test.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Error: execution of an external program failed

== nim version ==
Nim Compiler Version 0.11.2 (2015-05-04) [MacOSX: amd64]

But this code can be compiled successfully.

proc printf(formatstr: cstring) {.header: "<stdio.h>", importc: "printf", varargs.}
printf("%d, %f, %s\n", 11, 33.3, "test")

[apense]

It's resulting from the C file having the same name as the Nim file "test." This is probably an error.
Try renaming the C file to "testc.c" or something in the meantime 😃 (this fixes it on my Win64).

FYI: the "test.nim" file is compiled down to "test.c". The compiler is probably mixing up that file with your own "test.c"

[Angluca]

Oh! You are right, It's ok now, Thank you.
Hope fix it in after version.

[apense]

Could you reopen it? Maybe make the title something like "Unable to compile external files with same name as module." You found a good issue. I don't think it's addressed anywhere.
EDIT: it should at least be mentioned in the documentation

[refi64]

Would a simple fix be to compile .nim files as .nim.c?

[shaunc]

+1 -- just hit this, and seems important for scalability: if you have a large tree of modules from various sources, its alot of coupling to force all modules to share the same namespace regardless of path.

Also, this is probably important for nim-lang/nimble#131

[Varriount]

@shaunc any ideas for a solution?

[shaunc]

@Varriount -- name munging? Perhaps simplest would be just to have a counter for each module and prefix or suffix that counter to the module name, then rewrite references to it. This is the approach that babel uses to transpile es6 imports to es5 in javascript.

[Araq]

The compiler uses pkg_module.c if you use a pkg.nimble file. It scales perfectly well if you use Nimble packages.

[shaunc]

@Araq -- the thrust of nim-lang/nimble#131 (as I would like to see it anyway) is to avoid any unnecessary coupling between package version decisions. (There is necessary coupling, sometimes -- enforceable with something like npm/peerDependencies.) So if package x has a sub-dependency w/ version 1.0.0 of package z, and package y uses version 2.0.0 of z, a project can use both x and y without problems and they are linked to the appropriate versions of z.

Is there a mechanism to manage this (x_z_module.c vs y_z_module.c)? If not, I think there still is a scalability issue. The beauty of npm is that major projects can have 100s of dependencies nested 5 or 6 levels deep, and everything still works even if all the package maintainers don't move in lockstep to support new versions of subdependencies. This makes it much less costly/risky to hive off subdependencies, which is exactly what happens. These simpler sub-pieces attract community support more easily.

[Araq]

If not, I think there still is a scalability issue.

Well I left the issue open for a reason.

[shaunc]

Thanks so much for nim! :) ... I'm learning nim because I need to write a custom index library for in-memory distributed analytics. Not anything I should do in js or python and this seems way faster than c++ development. "Scalability" in terms of hoards of developers working simultaneously on 1000s of projects is a problem I wish on you. :)

[narimiran]

Works in Nim 0.19.9

[shaunc]

Awesome! :)