[fpc-pascal]The state of FPC (was: Synapse for FPC)

[Mattias Gaertner]

On Thu, 24 Jul 2003 15:17:50 +0200 (CEST)
marcov at stack.nl (Marco van de Voort) wrote:

> > > You can simply make a preprocessor which does that if you find it fun
> > > to
> > do.
> > > But this doesn't change the unit structure, and gives no advantage in
> > > maintainability at all. At most the end user finds it easier to read
> > > the sources.
> > 
> > Your final line is the reason I mention it in the first place. The
> > include file system may be lovely for yourselves, but it is a mess imho.
> > I have to look at 3 files before I find the piece of the source I want
> > to look at, and even then I have to switch between the Interface and
> > Implementation includes!!!!

Yes, this is really pain under Delphi.


> It's a matter of taste, but don't forget otherwise you have to
> scroll/search through the same amount of info. I really dislike units that
> are longer than 1000-2000 lines.
> 
> In time Lazarus could be adapted to make things a bit easier (e.g. opening
> all includefiles too when opening an unit, 

Lazarus opens the include files internally. I don't think that many users
wants to open the 20 include files when opening classes.pp. They are opened
automatically when you do for example a method jump or a find declaration or
doubleclick on a codeexplorer item.
I think, an overview of the include files would be nice. I think, the code
explorer is a good place for this. Any ideas, how this information should be
merged into the code explorer?


> and clicking a {$I ..} line switches to it or so.

"Find declaration" and "open filename at cursor" does this.

 
> [...]
> 
> > I think the end user would benefit from the 'preprocessed' units at
> > release time, and the developers would keep whatever grand scheme they
> > desire at development time.
> 
> How do you merge back user fixes then? Do you want to distribute each unit
> for each platform-OS version? Would become a huge source zip then.

.. and think about bugreports and other communications referring to files
and line numbers. This can become a tower of babel. 

  
> [...]
> Putting more stress on the core team (this is yet another nail on the
> coffin) would grind development to an halt. Why do you think that sysutils
> unit is lagging behind?
> 
> The only systematic solution would be more people. And not in the future
> (people have been saying that for years), but NOW.
> 
> Extra people don't have to be really hardcore developpers:
> - People that get a kick out of helpdesk work can always apply ;-)
> 	(answering questions, bugreport analysis)
> - Intermediate users that compile a lot of Delphi code, and make a very 
> 	precise analysis of what is wrong, and how to fix it.
> - we still need a webmaster
> - documentation. (Michael does this nowadays), both making it and 
> 	proofreading.
> - making headerconversions.
> - making demoes
> - be Lazarus liasions officer.

:)


> - somebody to look into the win32 net-installer thing.
> 
> And the list goes on.
> [...]


Mattias