Improve Nim language support as `target`

[griffith1deady]

Xmake Version

xmake v2.9.9+dev.a6af349ad, A cross-platform build utility based on Lua

Operating System Version and Architecture

Windows 11 IoT 24H2

Describe Bug

The essence of the problem: if you use a single-file project, everything is fine. If you make a project with any structure that includes for example:

main.nim:

import something
echo "Hello, world!

something.nim:

echo "Hello from something!"

At the first compilation everything will be fine. but if you only make changes to the files on which add_files("src/main.nim") depends, the target will not rebuilded. Also, add_files("src/*.nim") does not solve the problem, because each file will be built as a separate application, which is unacceptable.
I love xmake and use it extensively with nim, but now I have to use task which will run os.run("nim c ...") because there is no support for anything more complex than a single-file project, but I love the work done on xrepo. also, passing arguments to the native linker or native compiler doesn't work properly, causing the nim compiler to think we're trying to pass arguments to a running application and display an error.
also, importc paired with add_deps/add_packages won't properly link static/shared dependencies for some strange reason.

Expected Behavior

• Correctly rebuild target when project files changed, not only main target file;
• Correctly link static/shared dependencies (also can come from xrepo);
• Correctly pass linker/compiler argument's as passL:"..." and passC:"..." to nim compiler

Project Configuration

target("sellage")
set_kind("binary")
add_files("src/main.nim")

see $describe bug for project example

Additional Information and Error Logs

None. I don't remember all aspect's that not work with static/shared dependencies, but i can to deal with it later if the problem is not on the surface.

[waruqi]

Incremental compilation is not currently supported because it is not known how to analyze and obtain their dependencies.

[griffith1deady]

Incremental compilation is not currently supported because it is not known how to analyze and obtain their dependencies.

I'm not talking about incremental builds, I'm talking about rebuilding the target if the project files have changed? That's different, no?

[waruqi]

If we just rebuild the entire project, it works for me.

ruki:console ruki$ xmake
[ 63%]: linking.release test
[100%]: build ok, spent 0.359s
ruki:console ruki$ touch src/main.nim
ruki:console ruki$ xmake -v
[ 63%]: linking.release test
/usr/local/bin/nim c -d:release --nimcache:build/.gens/test/macosx/x86_64/release/nimcache --passL:-s -o:build/macosx/x86_64/release/test src/main.nim
[100%]: build ok, spent 0.363s
ruki:console ruki$ touch src/main.nim
ruki:console ruki$ xmake -v
[ 63%]: linking.release test
/usr/local/bin/nim c -d:release --nimcache:build/.gens/test/macosx/x86_64/release/nimcache --passL:-s -o:build/macosx/x86_64/release/test src/main.nim
[100%]: build ok, spent 0.356s

[griffith1deady]

If we just rebuild the entire project, it works for me.

ruki:console ruki$ xmake
[ 63%]: linking.release test
[100%]: build ok, spent 0.359s
ruki:console ruki$ touch src/main.nim
ruki:console ruki$ xmake -v
[ 63%]: linking.release test
/usr/local/bin/nim c -d:release --nimcache:build/.gens/test/macosx/x86_64/release/nimcache --passL:-s -o:build/macosx/x86_64/release/test src/main.nim
[100%]: build ok, spent 0.363s
ruki:console ruki$ touch src/main.nim
ruki:console ruki$ xmake -v
[ 63%]: linking.release test
/usr/local/bin/nim c -d:release --nimcache:build/.gens/test/macosx/x86_64/release/nimcache --passL:-s -o:build/macosx/x86_64/release/test src/main.nim
[100%]: build ok, spent 0.356s

we are talking about different things. what I am saying is that if another project file on which the main project file depends is changed, no recompilation takes place. but you are talking about changing the main file via touch. this applies not only to that. also to changing nimble dependencies, locally. also compiletime execution depends on the nim compiler running all the time. what I mean is that the nim compiler should be run every time, not just when the main file is changed. this is the difference. the current implementation is fundamentally flawed.

[waruqi]

I still don't understand what you are saying. Can you provide a complete reproducible project and commands?

[griffith1deady]

after initial build, where
something.nim:

echo "Hello from something!"

main.nim:

import something
echo "Hello, world!"

after echo Hello from something!
add these lines:

import std/[times]
const buildTime = getTime()
echo "Project builded at: ", buildTime

and run xmake or xmake b target
no rebuild will happen.

it's just a simple example, that will crash compiler initially, but after initial compiling run xmake -f
and you will see:

PS C:\Users\griffith1deady\Desktop\xmakenim> xmake -r
[ 66%]: linking.release sellage.exe
error: Hint: used config file 'C:\Programming\Native\Languages\Nim\config\nim.cfg' [Conf]
Hint: used config file 'C:\Programming\Native\Languages\Nim\config\config.nims' [Conf]
................................................................................................
stack trace: (most recent call last)
C:\Users\griffith1deady\Desktop\xmakenim\src\something.nim(4, 26)
C:\Programming\Native\Languages\Nim\lib\pure\times.nim(981, 25) getTime
C:\Programming\Native\Languages\Nim\lib\pure\times.nim(976, 3) getTimeImpl
C:\Programming\Native\Languages\Nim\lib\std\assertions.nim(36, 13) raiseAssert
C:\Programming\Native\Languages\Nim\lib\system\fatal.nim(53, 5) sysFatal
C:\Programming\Native\Languages\Nim\lib\system\fatal.nim(53, 5) Error: unhandled exception: implemented in the vm [AssertionDefect]

nim target's should be builded forcefully every time xmake or xmake b target is executed.
nim compiler is smart enought to not recompile every nim/c files without need already