Re: Is FPC an option in BDS because of MSBuild?


"Dean Hill" <none@xxxxxxxx> wrote:
Danikl Mantione wrote:

designed to refactor FPC source code. Lazarus codetools, on
the other hand are designed to parse and process FPC code, and
more suitable for FPC codebases, such as better help you make
use of include files than Delphi does.

Fair enough.

I assume you will install your components once and then
develop with them. Even considering that you do it more often,
the recompile is a user friendly automated process that
takes about a minute on a pc made within the last 2 years. So,
no, I do not agree that this can be a problem for people.

I suppose it's just habit that makes one a little reserved about
rebuilding your IDE.

The reason that Lazarus does it like this is that it is not
really a good idea to ship the FPC RTL dynamically linked.
There is no strict versioning in place to ensure backwards
compatibility, which makes that it would become a big mess
if we would link everything to a rather large libfpc.

Another issue is PIC versus no PIC. Enabling PIC slows down
code by 15%, which is quite a heavy price to pay. So, Lazarus
needs the components in the IDE executable and do this easily
since it is open source.

For the ones that don't even have source code that is not an option.

They will never work with FPC then. What do you expect, that
we're going to offer binary compatibility with Delphi
components and magically make them cross-platform? I am afraid
that is impossible.

You misunderstand me. I was thinking more on the lines of: What about
one of those vendors wanting to sell into the FPC/Lazarus market? The
only way they could release their IDE expert is with source code which
should not be a requirement for a tool.

This is indeed a problem, both technically and legally. The
legal problem is the easiest to solve, simply grant a GPL
exception.

The technical problem is to keep components working. The
slightest change in an OOP object will change the VMT layout
making the code backward incompatible. Delphi doesn't solve
this, you need to release your components for each Delphi
version. For Lazarus this would be more problematic, because
it is released more often, requiring people to ship much more
versions of their binary components.

Do you really believe you can load your Delphi components into
Eclipse? No of course not. The only way to load components at
all is your own IDE.

Or perhaps a host that resides in the IDE. This has always been the
problem.

Do you really think that Eclipse can parse Free Pascal code
and refactor it? Or support a the Pascal way of doing RAD?

The C++ guys are doing that with Eclipse http://www.eclipse.org/cdt/

You can write a Pascal parser for Eclipse, yes, but you are
limited what you can do. To be able to browse symbols you need
the browser info from the compiler. Forget about RAD because
this requires close cooperation from compiler and IDE.

Yes and no. Lazarus and FPC are separate open source projects.
Someone who is able to program a great form designer is not
necessarily a good compiler engineer that can write a register
allocator.

Fair enough

of full time Codegear engineers. But that has never been the
plan anyway. Free Pascal doesn't do what Delphi does, it does
do what Delphi doesn't do.

But that is always going to be the comparison. People typically want
to work in one environment or at least equal environments. Switching
from IDE A where you can do A..Z to IDE 2 where you can't do B,C and D.
People get a comfort zone and prefer to work in that environment. My
guess is that is how CrossKylix and CrossFPC came into being and why
there are people using BDS to build .NET applications. FPC can do what
Delphi can't do (Multi-platform) and most of what Delphi can do.
Lazarus can to what Delphi can't do (Multi-platform) but significantly
less (as opposed to FPC) of what BDS can do. That is why there will be
the temptation to use FPC with BDS.

Sure. With al respect to Simon Kissel, there are limitations
to what you can do with a plugin. Simon is a smart coder, so
I'm sure he's capable of finishing his project. The result in
the end, will be more or less that you can use Delphi to start
a compilation with FPC. This will be most minimum of IDE
integration there is.

Proper IDE integration is only possible with the Delphi source
code, and even then far from trivial.

Daniël Mantione
.

Relevant Pages

  • Re: Why arent you upgrading?
    ... Stable IDE - this is first and foremost before anything else. ... MS alternate choice - As I see it the reason Delphi became so ... better database support ... Then announce that 64-bit native compiler is in progress and started. ...
    (borland.public.delphi.non-technical)
  • Re: Is FPC an option in BDS because of MSBuild?
    ... Delphi is more powerfull than Lazarus and this is unlikely to ... Delphi" will every become. ... a "FPC inside Delphi". ... Delphi IDE refactors *Delphi* source code, ...
    (borland.public.delphi.non-technical)
  • Re: .Net applications, not optimized for CPU at all?
    ... as a class is referred, all its virtual methods are included, even if they are ... But all code is in the .dcu too, so the native compiler also preserves ... IME when compiling code with FPC, smartlinked, stripped, and comparing the ... FPC binary was often close to the same size as a non-UPX'ed Delphi binary. ...
    (borland.public.delphi.non-technical)
  • Re: Oh man!
    ... a native code DELPHI language IDE. ... platform. ... I dont even want the IDE - just a cross compiler would be ... You could write the code using Delphi on windows and then cross compile it to any platforms supported by FPC/Lazarus. ...
    (borland.public.delphi.non-technical)
  • Re: Is FPC an option in BDS because of MSBuild?
    ... Delphi is more powerfull than Lazarus and this is unlikely to ... Delphi" will every become. ... a "FPC inside Delphi". ... out-way the benefits of a multi-platform IDE. ...
    (borland.public.delphi.non-technical)