Especially for using NIM for embedded development I find the selection of supported compilers somewhat slim. Even for my offline Windows-box I have serious difficulties to get a C compiler working. (The installers of all compilers I donwloaded fail without internet connection). The nearly uncommented nim.cfg file is not of much help either.
So while I learned, that --passl and --passc options exist, these seem only able to add options to compiler and linker respectively. Currently I have selected to generic ucc compiler, but get the error
unknown option /o
and I have no idea, how to modify or replace that.
First you have to select compiler family (vcc, gcc, clang, etc.). Then provide executable paths. Then the options. E.g.
Emscripten (clang family):
nim c --cc:clang --clang.exe=emcc --clang.linkerexe=emcc myFile.nim
nim c --cc:gcc --gcc.exe=i686-w64-mingw32.static-gcc --gcc.linkerexe=i686-w64-mingw32.static-gcc myFile.nim
Etc.
Actually getting the compiler called was not the problem, but supplying the options for the compiler.
Are any options necessary beyond the optimization ones for speed/size?.
Can these also be specified (with something like --comilername.options=...) and if so, using which combination of "-" and "."?
...cc.exe -c -IC:\Nim\lib -o ..\nim\nimcache\hello.o ..\nim\nimcache\hello.c
Apparently the "-o" option is not understood by the Pelles C compiler. I would prefer to have it configurable in the nim.cfg file in a line like
ucc.compile.command = somepath/cc /Fo:%modname.o -c %modname.c
ucc.link.command = somepath/cc %modname.o %modname.exe
with a placeholder like %modname to be replaced by whatever module to compile.
A solution like this would be easier, more generic and more powerful than existing combination of ucc.path config file entry with passl and passc options combined.
"compiler family" is a perfectly fine term.
Pelles C used to be supported, try cc=pcc:
# Pelles C Compiler
compiler pcc:
# Pelles C
result = (
name: "pcc",
objExt: "obj",
optSpeed: " -Ox ",
optSize: " -Os ",
compilerExe: "cc",
cppCompiler: "",
compileTmpl: "-c $options $include -Fo$objfile $file",
buildGui: " -SUBSYSTEM:WINDOWS",
buildDll: " -DLL",
buildLib: "", # XXX: not supported yet
linkerExe: "cc",
linkTmpl: "$options $buildgui $builddll -OUT:$exefile $objfiles",
includeCmd: " -I",
linkDirCmd: "", # XXX: not supported yet
linkLibCmd: "", # XXX: not supported yet
debug: " -Zi ",
pic: "",
asmStmtFrmt: "__asm{$n$1$n}$n",
structStmtFmt: "$1 $2",
packedPragma: "", # XXX: not supported yet
props: {})
That said, Pelles C (and Borland C and Digital Mars C) had just too many bugs to support them. I don't think bootstrapping ever worked with Pelles C. As of 2016, there are really only 3 widely used C(++) compilers left: Clang, GCC and Visual C, so there is hardly a need to make the configuration system even more generic.
I have serious doubts concerning concentration on 3 compilers when in embedded environment the compiler is likely to be produced by a company, one may never have heard of before
Most embedded compilers follow GCC though when it comes to command line options, many are forks of GCC in fact. But you can also use --compileOnly and compile the .c files in nimcache on your own.
The problem could have been easily avoided by providing an option to generate C files only without attempt to control the compiler based on obscure (read: mostly undocumented) information
How so? And what exactly needs to be documented? I'm too dumb to see what needs to be documented here:
cc = gcc
# additional options always passed to the compiler:
--parallel_build: "0" # 0 to auto-detect number of processors
hint[LineTooLong]=off
#hint[XDeclaredButNotUsed]=off
# example of how to setup a cross-compiler:
arm.linux.gcc.exe = "arm-linux-gcc"
arm.linux.gcc.linkerexe = "arm-linux-gcc"
mips.linux.gcc.exe = "mips-openwrt-linux-gcc"
mips.linux.gcc.linkerexe = "mips-openwrt-linux-gcc"
...
# Configuration for the LLVM CLang compiler:
clang.options.debug = "-g"
clang.options.always = "-w"
clang.options.speed = "-O3"
clang.options.size = "-Os"