Generate a compiled version about rubberduck

[retailcoder]

Rubberduck is not currently able to compile VBA code, although its guts are probably something like 80% of the way already, however we do not intend to do this. Rather, we might (eventually... think v4.x) look into feeding the VBA code as-is to twinBASIC (tB), and have tB (100% VB6/VBA compatibility!) compile the native code. twinBASIC executables are extremely small and performant, and require zero dependencies.

[pflugs30]

I'm interested in something like this idea, too. I've tried building something of a Continuous Build / Continuous Integration pipeline for VBA projects, and I've wanted to build the code from an automated process. I've learned it's not a simple task... :-)

[daniellellouche]

Cool. Thk answering so fast Cdt Daniel XSBS, how to connect SAP and Excel [phone]

…

________________________________ From: Mathieu Guindon ***@***.***> Sent: Friday, May 5, 2023 7:07:15 PM To: rubberduck-vba/Rubberduck ***@***.***> Cc: Daniel Lellouche ***@***.***>; Author ***@***.***> Subject: Re: [rubberduck-vba/Rubberduck] Generate a compiled version (Issue #6108) Rubberduck is not currently able to compile VBA code, although its guts are probably something like 80% of the way already, however we do not intend to do this. Rather, we might (eventually... think v4.x) look into feeding the VBA code as-is to twinBASIC (tB), and have tB (100% VB6/VBA compatibility!) compile the native code. twinBASIC executables are extremely small and performant, and require zero dependencies. — Reply to this email directly, view it on GitHub<#6108 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/APHAQP4ZA6HV5HCUCIH4O63XEUXUHANCNFSM6AAAAAAXXGWMXA>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[retailcoder]

RD3 is going to capture a lot more symbols than 2.x ever did, and a type system is being crafted; the idea is simply to adhere to the language server protocol (LSP), and we'll have to see exactly how much more detailed we get, but between capturing every single symbol / resolving a type for every single one of them, and actually interpreting user code, the gap is seriously narrowing.

However, compilation is out of scope for 3.0; we'll cross the bridge when we get to the river, but it wouldn't be impossible to leverage twinBASIC for this, although it would probably be 32-bit executables and libraries (tB does compile x64, but not for free!) - in theory the Rubberduck Editor could talk to the tB language server in exactly the same way it talks to the Rubberduck language server, too, so there's absolutely going to be something to explore in that area, perhaps around v3.1!