Running "luisa-render-cli" on Windows prints / renders nothing, "luisa-render-cli.exe" works fine though.

[NeedsMoar]

I'm just going to throw in that I hope this renderer gets a USD frontend, it reminds me of Maxwell but I could only run that on a 4 core CPU when I had access.

Describe the bug
The title pretty much says it. Looks like it's identifying itself by name and needs the extension, but it's not common practice to type the extension of .exe files in Windows; scripts maybe, but not EXE

To Reproduce

1. Build luisa with defaults
2. Try to do anything (blank command line works) with luisa by using

>luisa-render-cli

3. Observe that nothing is printed / done.
4. Now run with .exe at the end.
5. Everything works as expected, no issues rendering or printing help.

Expected behavior
Windows programs with executable extensions shouldn't need them typed in to run / identify themselves.

Screenshots
N/A

Desktop (please complete the following information):

• OS: Windows 10 Pro Workstation
• Running on a regular old NTFS drive, no junctions or symlinks or anything silly.

Additional context
You guys should submit this project to the Guiness book of world records as the first non-trivial open source project that actually builds correctly on Windows. I'm sure there are others, but anything which requires the ultra-hacky msys2 or cygwin because somebody is still using an archaic build system that doesn't have a native port because, well frankly gnu autotools is garbage to begin with, doesn't count, and that's pretty much everything.

[Mike-Leo-Smith]

Hi, @NeedsMoar

Thanks for the rich information! It helps a lot for us to immediately confirm the cause of the bug: we use the canonical path of argv[0] to get the DLL dir and when .exe is missing, std::filesystem::canonical() fails and the renderer aborts. Hopefully, we'll soon fix it with more robust EXE path detection using Win32 API.

I'm just going to throw in that I hope this renderer gets a USD frontend, it reminds me of Maxwell but I could only run that on a 4 core CPU when I had access.

Sure it would be very cool to have a USD frontend for convenient data exchange with other DCC. However, I am not sure about the actual workload and sadly cannot give a promise right now. We are also investigating the integration into Blender and maybe USD-Blender-LuisaRender is also a possible path.

[Mike-Leo-Smith]

I believe it's been fixed in d444e40...a0089cb

[NeedsMoar]

No problem!
I'll confirm when I build again but that looks like it should fix it.

[NeedsMoar]

Forgot to close this, but it works
As a side note I suggested USD because aside from blender, Houdini (what I'm using, or at least learning to use since it's one of the more complex software packages in existence in any category) has heavily adopted it and the NVidia Omniverse software that's free with RTX cards has a realtime USD scene composer. From what I gathered in some of the USD to renderer adapter files in houdini they're basically all autogenerated from a set of definitions of how the target renderer expects things so it might be easier than it seems given that your scene DSL isn't doing anything crazy and is a text-based format. Anyway looking forward to seeing what happens in the future, cheers.