Open daniellellouche opened 1 year ago
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.
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... :-)
Cool. Thk answering so fast
Cdt Daniel
XSBS, how to connect SAP and Excel +41 78 892 04 68
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 GitHubhttps://github.com/rubberduck-vba/Rubberduck/issues/6108#issuecomment-1536543130, or unsubscribehttps://github.com/notifications/unsubscribe-auth/APHAQP4ZA6HV5HCUCIH4O63XEUXUHANCNFSM6AAAAAAXXGWMXA. You are receiving this because you authored the thread.Message ID: @.***>
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!
Justification I have bought a version of DoneEx VBA compiler software that compiles a selected workbook Idea is good however not easy to orchestrate. Considering the framework proposed by RubberDuck, I would see this compiling option as a ++ to the IDE. Not only, but the compiled version runs much faster :-)
Description DoneEx idea consists in creating a separate DLL which source code is in C language, converted from the VBA. At the same time inital VBA code is fully emptied of initial cade, whereas all routines and functions are outsourced in the DLL. The idea is good however requires users to implement the DLL which is not always easy in professional case. I would suggest to build an XLL instead which includes all components. Also the conversion to C Language is to me too complex, VB .net should be straight forward