Can’t compile for Windows I don’t think.
After spending some time digging into the details of LLVM, its not ready for prime-time. Much of the code will need to be written (or old code rewritten) to make is work with the new Clang/LLVM versions. LLVM is suffering from the same issues that ‘the other’ language is using, meaning that changing code for the sake of change is better, and often the Clang/LLVM is mentioned as bleeding-edge.
I am seeing two (?) possible options, and feel free to let me know of more:
-
Write a transpiler the way that @DaveS was mentioning, which may look something like this:
a) Code from Objio Windows would be transpiled into C++ visual studio code
b) Code from Objio Mac would be transpiled into Swift code
c) Code from Objio Linux would be transpiled into C++ code (not sure of the name of the standard C++ editor). -
Use another language like Kotlin (lots of good discussion on this topic), and transpile Objio (Windows, Mac, Linux) into Kotlin code and create each executable.
Clang does not seem to be ready for GUI, which is funny in a sad way, as Python 3.x is further developed than Clang.
LLVM is a good compiler, it just needs the Clang frontend to be more mature.
These are just my humble thoughts, and feel free to correct me 
I’m sure there are many large tech companies that rely on / leverage LLVM that would say it is ready for prime time
LLVM is just the toolkit for creating a compiler - not a compiler in and of itself
You (the language writer) have to supple the front end that emits LLVM IR
LLVM then can, with the application of various “passes” compiler & optimize the code
And then a specific back end can be used to emit one of many specific machine code versions (as .o file)
And finally you link the whole mess together (using LLD)
the even have a discourse with a Beginners area 
Maybe I misunderstand your concerns about LLVM ?
1 Like
Another idea I’ve had is approaching @dwarfland and asking about licensing their upcoming Mercury (VB) compiler and writing a Xojo-like IDE as a front end for it. RemObjects (who wrote the Elements compiler) have very publicly stated that they aren’t interested in creating a tool that is a write once use everywhere application. They also don’t seem to interested in the GUI side of things.
The great thing about Elements is that it it’s an open ecosystem that can use third-party libraries and tools — both those developed for one of the platforms in general, but also those developed specifically for Elements.
While we’re not currently working on a design-once-run-everywhere UI layer (though i’m not ruling it outer for the long term future either, we’d more than welcome anyone wanting to build such a library on top of core Elements (and, if it’s well done and compatibility with our vision) would certifiably also be open to discussing creating hooks for letting a designer for it be integrated in Fire and/or Water and creating a feasible distribution/licensing model for it.
Please ping me privately if you wanna explore this further.
1 Like
Hi Norman,
Yes, I could have written my response better, you are correct.
I agree that larger companies that are able to put many hours towards can create the code to make LLVM work well. For our smaller group, the LLVM would work, the main issue is that many of the libraries for creating GUI work appears to be custom. Maybe there is a library for the LLVM GUI that is available, and I wasn’t able to find it on a few searches and support forums?
When I compare this to Visual Studio, the libraries, support, documentation, and example programs appear to be readily available. When trying to make the Clang/LLVM create a GUI on Windows, it involves rewriting Visual Studio code that has been created, or working directly with the API. The API work is what I was doing with ‘the other’ language and now it makes sense as to the reason why - since they are both using LLVM or possibly Clang/LLVM combination.
LLVM does have its place, as it was easier to find information on cross-compiling. Installation of Clang/LLVM was challenging, as there are many versions of Clang/LLVM which are not backwards compatible, so you need to reinvent-the-wheel when updating Clang/LLVM.
There is the ability to use Clang and LLVM in Visual Studio, and then rewrite the libraries. However, the native libraries are compatible with C++ and the Visual Studio IDE. It just appears that the Clang/LLVM needs more time for developers to create libraries. Its a monumental task for the Clang/LLVM developers, and I pay my professional respects to them, as this is indeed a lot of work.
I’ll retract my statement, that Clang/LLVM is ready for primetime, although I will use the Caveat that it is more suited for larger companies. Is that a fairer comment? 
Comparing LLVM to VS is not really the right kind of comparison - IMHO
Clang/LLVM is a more suitable comparison to VS - and since it isnt the default for VS its probably awkward at best
LLVM is more directly comparable to Roslyn - the .Net compiler infrastructure
1 Like
That is a fair statement, for sure. The Clang/LLVM vs Visual Studio are comparable. The difference that I see is the number of libraries for Visual Studio when comparing to Clang/LLVM.
I am unsure why Clang/LLVM would have less libraries for creating common items such as Forms (Windows), controls, etc. Maybe it is because Clang/LLVM targets many platforms? Following that train-of-thought, then there should be more libraries, since the developers of many platforms may (?) have developed these controls?
Just thinking out loud.
Does anyone on this forum know of libraries that can be used to create a cross-platform GUI on Clang/LLVM? I am willing to give it a go
I’d guess it has more to do with how long they have been available on each platform
Personally I’m almost inclined to look at wxWidgets for a ui toolkit
Native widgets every where
That said I have started crafting a Xojo grammar for ANTLR - yet another compiler construction tool
ANTLY has the nice side effect of being able to emit the code if generates for Swift C# C++ Java and several others
I’ll have to post this somewhere
1 Like
Maybe wxWidgets OR maybe do something different and dot be limited with the Least Common Denominator for native, use a true cross-platform GUI like GTK on Windows, Mac and Linux, full support for modern Layout Containers and controls. Using of course the powerful vector graphics-based, device-independent drawing library cairo.
Well, I have it working with the Windows API on Windows 10 using Clang/LLVM. Here is a screen grab of the running program:
The file can be downloaded here:
Zipped Winform.exe
Creating a form and GUI can be created with Clang and LLVM. An interpreter would be needed to convert it to Clang.
Edit: The executable is tiny at 92 KB.
2 Likes
Great idea! I’ll need to dig through the LLVM documentation a little more and see if wxWidgets would work. If they work then the big-three operating systems (Windows, Mac, Linux) can have executables built.
For writing an own Compiler to use a Linux System to rewrite the LLVM and after it to compile itself under Windows and MAC it should be good enough. I don’t like this thinking. Of coarse you will not get a ready solution for free, I am sorry. When I said take a look at Gambas I ment to have the fundament of a working Basic dialekt. To bring it to Windows and Mac you will have to work on it. But that was the diskussion byself. Writing a Compiler and IDE for Cross Platform Development. And Gambas at least can write LLVM Code. So why not working on that instead of moaning that it is only for Linux?
Please don’t misunderstand me @thorstenstueker, Gambas is a good suggestion. I’m not against writing a compiler from scratch so doing some extra work to support a different platform for Gambas is not ruled out. I think people are just exploring what is the best solution before moving forwards with the project.
It is the best Solution cause they already have the ability to work with llvm. It would be the shortest way to a new IDE and Compiler in cross platform wise. There is a good chance to do. Otherwise we will loose them to the mono project and dotnet and c#
If the VB/VS route is taken, I’m fearing the upcoming product will be like many others: Windows-centered (my opinion).
I’ll probably never use VS because Mac is just a marketing argument for them; they don’t care that much.
And also because I hate some of its properties (the “set” keyword, weak typing, no real “folder item” class, Windows named “forms”, etc.). At least, that’s how it was the last time I used it.
I’d stay with Xojo if there’s no good Mac alternative (other than Swift and similar languages where there is more punctuation than words).
My personal opinion.
B4X compilers do generate native code (or Java on the desktop) which is then compiled with the native compiler, however the B4X compiler could have generated lower level objects. The compiler isn’t tied to the underlying language.
There are actually advantages for such tool-chain as the native compilers include very sophisticated optimizers.
It also allows embedding native code which is an important feature.
Building a debugger with hot code swapping, that works with Android and iOS devices is indeed a very difficult task and it took years to develop.
3 Likes
There’s no space for a new VB. VB.Net with the upcoming xplatform DotNet 6 and xplat UI (MAUI) will be much more mature and free. Not Win centered anymore, but really not “Linux emphasized” because Microsoft will offer MS Engineers to work in the MacOS, iOS, Windows and Android but said that for Linux the community should take care of it (envy of the full support Canonical (Ubuntu) did to Flutter?).
1 Like
Ambitious roadmap AND timeline (nov 2021 for a GA release ?)