The codebase can easily be built with MSYS2's Clang on Windows, but `bl-config` demands MSVC tooling no matter what

[Akira13641]

It would be great to have the option to generate a MINGW-tools-based config file instead of an MSVC-tools-based one.

[travisdoor]

Hi thanks for the report, I'm currently changing the way bl-config works. I'm still not sure about the final decision, but I'm currently experimenting with YAML based config capable to handle multiple environments. Lookup all MSVC stuff automatically is quite a pain, I'm not sure if MINGW will be easier or not...

[Akira13641]

Even if you provided a way to just like, generate any of the config file types at the user's discretion (so that they could then manually edit them if necessary) that would be good I think. Right now basically, even though it would probably be easy for me to edit the configuration file by hand, I can't, because there simply is no way to create a valid bl.conf without having the MSVC tools installed.

[travisdoor]

What about having something similar to rustup-init? I mean basically introduce some installation steps/options in bl-config.

[travisdoor]

There can be an option to create custom or empty config files the users can play with... at least until we have some time to deal with automatic resolving of dependencies for all possible toolsets on all possible platforms.

[Akira13641]

What about having something similar to rustup-init? I mean basically introduce some installation steps/options in bl-config.

That'd be good also yeah. Just anything that can get at least a basic example of the config file written out, pretty much.

[travisdoor]

You can try to experiment with this MSVC configuration from my machine and try to set it up for the MinGW toolchain, but it's definitely not tested. I can try to do some investigation in the scope of #154 task (there can be problems with libc wrappers or other things).

// BL configuration file
// This file is generated by bl-config tool and used by 'blc' compiler during compilation
// process.

VERSION "1.0.0"

LINKER_EXECUTABLE "" 
// Main API directory containing all modules and source files.
LIB_DIR "C:/Develop/bl/lib/bl/api"
// Default linker options used for executable linking.
LINKER_OPT_EXEC "/NOLOGO /ENTRY:__os_start /SUBSYSTEM:CONSOLE /INCREMENTAL:NO /MACHINE:x64 kernel32.lib user32.lib gdi32.lib shell32.lib ucrt.lib legacy_stdio_definitions.lib msvcrt.lib vcruntime.lib Shlwapi.lib"
// Default linker options used for shared library linking.
LINKER_OPT_SHARED "/NOLOGO /INCREMENTAL:NO /MACHINE:x64 /DLL kernel32.lib user32.lib gdi32.lib shell32.lib ucrt.lib legacy_stdio_definitions.lib msvcrt.lib vcruntime.lib Shlwapi.lib"
// Additional linker library path.
LINKER_LIB_PATH "C:/Program Files (x86)/Windows Kits/10/Lib/10.0.19041.0/ucrt/x64;C:/Program Files (x86)/Windows Kits/10/Lib/10.0.19041.0/um/x64;C:/Program Files (x86)/Microsoft Visual Studio/2019/Professional/VC/Tools/MSVC/14.29.30133/lib/x64;"

Saved into etc/bl.conf.

[Akira13641]

Thanks! I'll let you know if I come up with one that might be a decent outline for MinGW toolchain setups in general.