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

[Marco van de Voort]

> > 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!!!!

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, and clicking a {$I ..} line
switches to it or so.

I do have to acknowledge that when I started on core, it took some time
to get used to it though. However there is no other clean solution.

Don't forget that for e.g. 2.0 there will be about 20 processor-OS
combinations. 

Ifdeffing them all is simply not possible, and most system independant units
have a system independant part (header, but also utility routines etc) a
dependant part, and sometimes even a processor dependant part (but that
usually is much smaller)

> 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.
 
> Please understand, I do not mean you should change your way of working, just
> that the end user should not have to see your messy include file ridden
> source. Does that make sense?

"Messy" is your label, I don't consider it messy. It is close to the iron,
sure, but show me a large multi platform project that isn't.

Though there is some merit maybe in your arguing. While I don't feel like
distributing the mangled version, maybe the util that does that (for a
single unit or unit set) could. 

People that prefer it, or want to for debug purposes, can generate a fully
OS-platform dependant unit (without much ifdef or includefiles).

The systematic directory layout used in most places should make finding the
includefiles automatically easy. So only defines that are not strictly
about platforms are a problem, but those will be relatively small.

So that is maybe a good point. So all we need is an interested volunteer I
think.

 
> > When I was at borland for an interview, the first thing I asked was
> > support in the IDE for include files. They scratched their head, and
> > said they would think about it.
> 
> I'm pretty sure that the Unit files that are distributed by Borland are
> constructed by a script from a larger source repository. I doubt they work
> directly on the source files as we end users see them.

They probably have a full time helpdesk staff to deal with it, between users
and developpers. Under FPC, core does everything. Usersupport, documentation
development (there are 10 categories below this alone), bugrepport
analysise, release engineering, advocacy, website analysis, faq creation etc. 

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.

> > This is largely a matter of taste. In -Sd it is mandatory to use
> > Borland's way, so if you restrict yourself to that mode, you should
> > be fine.
> >
> > See: We accomodate most tastes :-)
> 
> Nice to see FPC has come along since I last attempted to use raw Windows API
> in it ;-)

Talking about raw api, maybe we should import Marcel van Brakels win32 API
into FPC 1.1.x (the same that Jedi advocates on its site). It is a bit biggish
though, first we need the net-installer then ;-)