The compiler should set the extension for the output automatically

[ghost]

bflat considers things without Main libraries and that's a feature, not a bug. I'll leave this open because the compiler could generate a warning if there's no UnmanagedCallersOnly methods with an entrypoint (the library is a non-sensical library, but it is a library nonetheless).

This is bflat's weirdness. I will note this. Thank you.

This app can't run on your PC - the output should have a .dll extension in this case. One needs to go out of their way to rename the file to get this failure mode.

Again, this is bflat's weirdness. Only bflat requires me to specify the executable name with extension, otherwise it will output an extension-less file. All other compilers choose the extension for the executable automatically.

Originally posted by @iahung3 in https://github.com/bflattened/bflat/issues/185#issuecomment-1968630679

[ghost]

bflat build will name the output the same as the containing directory. This is most of the time undesired, so an output name has to be specified with -o. But -o require the output to have extension. Otherwise, it will produce an extension-less file. This is something very weird. GCC, Clang, and all of the compilers I know, will set the output's extension automatically. gcc test.c -o test will produce an executable named test.exe on Windows. This is unfortunately not the case with bflat.

[MichalStrehovsky]

Clang, and all of the compilers I know

clang hello.c produces a.exe clang hello.c -o hello produces hello without extension

bflat build hello.cs produces hello.exe bflat build hello.cs -o hello produces hello without extension

I still thing bflat's behavior is very predictable and sane.

[ghost]

Clang, and all of the compilers I know

clang hello.c produces a.exe clang hello.c -o hello produces hello without extension

Which version of Clang are you using? I'm building software with MSYS2 CLANG64 on a daily basis, and I confirmed that it will always add an extension to the executable. a.out (and thus a.exe on Windows) is something from the legacy of the past.

clang hello.c -o hello will produce hello.exe

bflat build hello.cs produces hello.exe bflat build hello.cs -o hello produces hello without extension

I still thing bflat's behavior is very predictable and sane.

Yes, it's predictable, but it's not sane. It's only sane if you are building a single source file. Most projects consist of multiple source files. bflat build will use the name of the containing directory for the executable name. Well, I think it should use the name of the source file that contains the Main method as the name of the executable. But forget about that. What we are discussing is the behavior of the -o switch. I still think it should set the extension for the output automatically.

[MichalStrehovsky]

Which version of Clang are you using?

$ clang -v
clang version 15.0.6
Target: x86_64-pc-windows-msvc
Thread model: posix

Yes, it's predictable, but it's not sane. It's only sane if you are building a single source file.

The output file name is based on the first source file on the command line (unless it's the glob mode with no source files specified but nobody is forced to use that if they don't want). Can you order the files so that what you want is first? A rule that uses the file that contains Main doesn't work for shared libraries.

[ghost]

The output file name is based on the first source file on the command line

This information is useful. Thank you.