Forum > General
Can I setup Lazarus to use Virtual Pascal compiler and still debug?
marcov:
--- Quote from: MarkMLl on February 14, 2023, 10:09:53 am --- Noting Martin's and Mika's answers, since Lazarus is arguably the best available RAD IDE perhaps expanding it to support more compilers and languages would be a worthwhile goal.
The IDE, i.e. editor and debugger, is IMO at least as good as Eclipse and its open nature makes it attractive relative to MS Visual Studio. The form designer, generating XML and provably useful for multiple target OSes etc., is sufficiently capable that other language communities might consider implementing their own class libraries.
--- End quote ---
Usually this leads to a lowest common denominator IDE. One of the things I like about Lazarus is its sharp focus on Free Pascal. And those sunny uplands somehow never happen.
One way Designers are a dime a dozen. Truly two way designers (code manipulation and incremental GUI development) are rarer.
Thaddy:
Both Virtual Pascal and GDB can be setup as external tools.
Myself, I use Geany with a similar setup, but that is also possible with Lazarus.
Martin_fr:
--- Quote from: MarkMLl on February 14, 2023, 10:09:53 am ---
--- Quote from: marcov on February 14, 2023, 09:10:57 am ---No. And even if there were a theoretical possibility it would be magnitudes more complicated than fixing your porting issues.
--- End quote ---
Noting Martin's and Mika's answers, since Lazarus is arguably the best available RAD IDE perhaps expanding it to support more compilers and languages would be a worthwhile goal.
The IDE, i.e. editor and debugger, is IMO at least as good as Eclipse and its open nature makes it attractive relative to MS Visual Studio. The form designer, generating XML and provably useful for multiple target OSes etc., is sufficiently capable that other language communities might consider implementing their own class libraries.
MarkMLl
--- End quote ---
The IDE has support for plug ins already. Extensions for other languages can therefore be done as 3rd party add ons.
If those plug in interfaces are not sufficient, they can be extended. But that will probably only happen when someone actually shows that they develop such a plugin. (And "shows" in this context means, has already some code as proof of their intend).
Couple of other notes.
Debugger: For users of other IDE, there is a "DAB" interface (written by Joost) to FpDebug. (search wiki)
FpDebug: Is a generic debugging library. It has it's main focus on DWARF. However if someone would supply readers for other generic debug formats that would be within its scope. That would need continuous support as FpDebug is still being shaped... Maybe that could even be an addon package, not sure yet.
FpDebug, DWARF: The implementation has had it's testing against FPC only. But it should not be limited. If you have code by another compiler that generated *valid* DWARF, and FpDebug does not handle it, then that is considered a bug in FpDebug (or missing feature, since FpDebug's DWARF is not 100% complete yet). However since DWARF does not represent all Pascal structures sufficiently, the resulting display for non-FPC may be somewhat generic. If incorrect/buggy DWARF is produced, then it only counts as a bug if FpDebug crashes, otherwise any result (error or incorrect value / the latter, depends on the severity of the incorrectness) is acceptable.
The Display of values in the IDE is (and always will) be Pascal centric). For other display, a plugin would need to do that.
MarkMLl:
--- Quote from: Martin_fr on February 14, 2023, 10:37:48 am ---The IDE has support for plug ins already. Extensions for other languages can therefore be done as 3rd party add ons.
--- End quote ---
Can you point us (collectively) at documentation and examples?
I've always found the whole business of IDE extensions etc. to be extremely opaque: there's quite simply no indication of where to start.
Noting your points, I wonder whether having support for an external language server to help highlighting etc. would be useful (much as I dislike the current "rely on its being available in the cloud" philosophy).
MarkMLl
Martin_fr:
Generally, the package IdeIntf.
But yes there is limited documentation.
Yet the point is/was, if someone would write code to extend the IDE, and the interfaces weren't there, they need to study the IDE code. But if you do that, then the IdeIntf is covered by the gained knowledge.
There are packages that add menus, key-combos, or buttons to the IDE => so for that, examples of the Intf* can be found.
If you want to add some codetool replacement for another language, then that will likely need an extension. There is a unit to interface with the source editor.
For doing your own compilation: You could define a new set of keys. I am not sure if you can hook and catch existing commands, *before* their default handler.
(Though SrcEditorIntf gives you the TSynEdit, and you can hook that. But if focus is elsewhere in the IDE...., maybe one of the other *Intf units (search for "[User]Command"))
The debugger isn't currently replaceable....
Though search the wiki: Joost done some "add extra debug windows" in one of his DAB debugger packages.
Mind that the debugger code is currently more or less undergoing a major rewrite. (at the end of which I hope to add some Intf units)
Main entry point is probably TLazIDEInterface
Navigation
[0] Message Index
[#] Next page
[*] Previous page