[fpc-pascal] Systems 2005: A first summary

Sebastian Günther sguenther at gmx.de
Sun Oct 30 02:02:51 CET 2005


Tony Pelton schrieb:

> well, firstly, there appears to be at least one other decent IDE that
> i know of :
> 
> http://www.bloodshed.net/devpascal.html
> 
> but in any event, i'm not sure why that distinction is important.

Lazarus is the IDE important for over 95% of all people.


> i think the point of the bundling strategy is not in the number of IDE's.
> 
> i think there are a few more relevant points :
> 
> *) the IDE is kind of pointless without the compiler
> *) the compiler doesn't *require* the IDE.
> *) giving people a complete, one stop development solution is a good thing.
> 
> but like Java, i think it would be of paramount importance to make
> sure that the compiler can also standalone, without the IDE and it's
> runtime, for those that want to use alternative IDE's, or where you
> want to be able to integrate the compiler in with an OS distro or what
> have you ...

Of course. But we need more integration between both projects. FPC is
_not_ Java, but more like Delphi, so people are not aware of the fact
that there is a distinction between the compiler (plus low-level
libraries) and Lazarus.


> and if this were my project(s), i personally _wouldn't_ advocate for
> merging all of that stuff together.
> 
> i would keep the projects mostly seperate *except* for the front pages
> of either site, where i do my marketing spiel about how the projects
> are complimentary AND i would make sure the projects cooperate enough
> so that they can always be bundled seamlessly with each other, and
> each projects download page should offer their own product AND the
> bundled product.

Regarding bundling: Of course it will be still possible to download the
distinct parts. But even on the wiki, it will get compticated if you
have two wikis. What I have in mind is this: You're searching for a
special application, e.g. sound output (wavefile output). Then you have
only one single Wiki page which explains how to do that within Lazarus,
and how to do it without Lazarus. This would explain the inner workings
of any Lazarus automatically.


> another thing that most java ide's do, which may or may not apply to
> lazarus, is that most IDE's have the ability to support more than one
> compiler suite at a time.

Yes but that is quite meaningless for the case of Free Pascal. I don't
think that Lazarus ever will support the compilers of Delphi or Kylix.
Those both projects are more or less dead already (Delphi will be dead,
if Borland will continue their chosen path).


> having that type of decoupling and runtime compiler switching with
> Lazarus might be very handy in the future AND it would make it much
> easier for Lazarus and FPC to iterate versions on their own schedules,
> and allow users to upgrade just the parts that they need to, when they
> need to.

Yes. But what we need are two solutions: A simple version for the bulk
of people ("download this single package and you'll get everything you
need"), and the more specialized version, where you have better controls
about used versions etc.


>>There is no clear separation between FPC and Lazarus for the end-user.
> 
> 
> for a Lazarus end user I assume you mean ?

Yes and no. The average user doesn't know anything about FPC and Lazarus
at all. They know (or might know) Delphi, and recognise FPC+Lazarus as a
kind of substitute. But, as soon as they have a problem of any kind, it
gets complicated. For example. I've personally faced many questions on
the Lazarus mailing list, where Lazarus itself hasn't been the origin of
the problem, but units distributed by FPC have been.


>>For example, an average user cannot tell easily if he has a problem with
>>a component or function belonging to Lazarus or belonging to FPC.
> 
> 
> and again, if they were bundled together, but also properly
> modularized, if the FPC or it's runtime was to blame for a bug, or
> Lazarus was, the source of the problem could be better identified
> because of the modularization, and then just the suspect part could be
> upgraded to solve the problem, rather than having to download the
> whole big bundle, after the bundle has been updated by the responsible
> project.

The average user is not able to identify the correct source of any
problem. But if we can manage to provide a single source of
documentation (especially the Wikis), there is a chance that many of the
usual user questions will just drop out, making the whole support much
easier.


- Sebastian



More information about the fpc-pascal mailing list