Hi everyone, I would just like to raise awareness of a technical issue I have being having recently and start a discussion about this.
I have the standard Windows GUI build of cmake 3.19 installed on my PC here and it ships with an extremely helpful “Borland” generator included in the standard build by default.
However, when I look at my Windows System For Linux installation, also on my Windows 10 machine which uses cmake 3.16.3 from standard Ubuntu 20.20 LTS this version of cmake does not include the same Borland generator. This is extremly frustrating for me as I would very much like to like to use the cmake Borland generator within a bash script running under Windows Systems for Linux and can’t at the moment.
Reading online, my understanding is that these generator is still available, it is just excluded from the Linux cmake build because cmake devs have assumed in the past that no-one could possibly be building for Borland compilers in a Linux environment.
I would just like to flag the fact that whilst this decision might have been sensible in the past, with the rise of platform interoperability tools such as Windows System For Linux, a lot of these assumptions no longer hold true. Building for Windows compilers and IDEs in Linux can and does make sense in a lot of different situations.
Thus continuing to ship cmake with certain Windows generators disabled in Linux builds is arguably problematic and needlessly cripples cmake. Why not just ship CMake with all generators included and enabled by default on all available platforms and let users decide for themselves which generators they wish to use? IMHO this would be a better approach in the future.
Part of the problem is that when CMake is built for and running in a Unix-like environment (Linux), and is generating for a Windows-based tool (Borland or Visual Studio), how does it translate paths from one to the other? Even if we can come up with a well-defined way of doing that, we still have to teach CMake how to do it. (MSYS is a notable exception to this, since there is a well-defined mapping between an MSYS path and a Windows path.)
Also, in some cases, it’s not possible to detect things like Visual Studio installations from the Linux build because it requires things like access to the registry, or other Windows-specific APIs that may not be available in the Linux subsystem.
Hi Kyle, thanks for your extremly timely response.
For the path translation issue you could have a user-specified flag to specify this? This would obviously be off by default, but it could have some settings, and if set it would translate WSL unix paths to windows one - say by flipping the slash direction and changing “/mnt/c” to “C:/” or similar…
Is access to Windows APIs truly necessary for CMAKE? I figured it just worked on the basis of specifying paths to the bin folder for that particular compiler and the name of the compiler binaries, even for something like Visual Studio?
Ah ok.
That’s a real shame as I would love to be able to create a cmake files that build for both RADStudio and classic Borland compilers from within Windows System for Linux, but it doesn’t look like I will be able to do that easily.