Open pb-cdunn opened 5 years ago
Best solution so far:
from os import DirSep
from strutils import rsplit
const thisdir = system.currentSourcePath.rsplit(DirSep, 1)[0]
{.passC: "-I" & thisdir.}
You found the solution - tell the C compiler where the include files are. Why should Nim do this automatically?
Nim already does it automatically, but only for the current module. The behavior is different when I module is used from another Nim module.
The reason this should work for dependencies is the same as the reason it was already made to work for the current (top) module.
This remains a problem. I still don't understand the logic. Module A uses module B, and module B has .c
and .h
files. Module A does not know that module B needs those extra files. But module B compiles fine itself.
You can see my current solution here:
You can test this easily. Clone nim-edlib and switch to cpp
branch. Then cd apps; make
. That works. Then clear the cache and the .exe
, remove the -I
line from edlib.nim
, and try again.
~/.cache/nim/aligner_d/aligner.nim.cpp:10:10: fatal error: 'edlib.h' file not found
#include "edlib.h"
^~~~~~~~~
related to https://github.com/nim-lang/RFCs/issues/510 ; please check whether it's an exact dup or not
Hmm. Not quite the same, but yes, related.
When I build/install a particular module, everything is fine. I have a hybrid package, with
.nim
,.c
, and.h
files, installed as both a library and as binaries. That works.The problem comes when I try to use it from another package.
Apparently, Nim fails to copy the
*.h
files into the compilation directory -- for dependencies only. The C codeDB.c
compiles fine because in C,#include "foo.h"
looks in the directory of the source-file. But the wrapperdaligner_dbx.c
, fromdbx.nim
(which has{.compile: "DBX.c".}
).See the problem?
Again, when I build the package that has the
.h
files, everything works, but that's because Nim automatically adds-I
for the current package, e.g.:See
-I/localdisk/scratch/cdunn/repo/nim-falcon/repos/nim-DALIGNER/src/daligner
? That's the key. I think the equivalent needs to be added when building dependencies.