[fpc-devel] Portability Standards

[DrDiettrich]

Florian Klaempfl wrote:

> >>- easier navigation in editors
> >
> > Definitely NO, with regards to include files! (May miss your point?)
> 
> Probably yes, you can easily open two editor windows viewing e.g.
> declaration and definition at once. Using splitted view is always a mess
> and requires mouse usage.

How do you "open two editor windows"?
In Lazarus I didn't find such a function yet, and using separate
instances of an IDE for work on the same project is not recommended
(concurrent save?)

---
I don't want to inititate an flame war about mouse usage and toolism,
but you should know:

It was in 1986 when I got my first Atari ST, because it had a GUI. Then
I found that I can work better with a GUI than with a command prompt.

I also prefer integrated tools, instead of an sea of tools for specific
tasks, coming with private and cryptic commands and arguments. In an IDE
the various components and commands must fit together, whereas separate
tools have nothing in common, by nature.

Some people use emacs as their IDE, but I cannot remember the many
keystrokes that are required to perform various tasks in such an
environment.

I accept that editing files should be possible without a mouse, but
sometimes it's easier to use a mouse for navigation and other tasks,
instead of the keyboard.

So much about my personal preferences.
---

> > 1) Navigation inside one file is more powerful (search, replace..)
> 
> grep/sed is more powerfull than any search/replae of an editor :) Even
> more if grep is integrated into the editor :)

As is the case with Delphi :-)

Grepping the FPC source tree doesn't distinguish between target specific
directories. This behaviour may be unwanted sometimes...

> > 2) How to determine all related files, e.g. for other targets?
> > 3) How many windows are required for one unit?
> 
> I don't know, but usually two are enough when modifying e.g. a class:
> definition and declaration.

For porting purposes various dedicated versions of the same procedures
or definitions (FPC/Delphi, Windows/Linux, C/Pascal...) must be
accessible concurrently. I also can configure in Delphi that I can jump
to a definition in an different file, that is displayed in a different
Window, so that the definition remains visible when I jump back to the
original location.

> > 4) Long search pathes require accordingly featured tools (target
> > switching...)
> 
> Well, this might be sometimes a problem, usually it isn't anymore.
> 
> > 5) How to produce diffs for multiple versions (targets) of one unit?
> 
> Modify it; do a
> cvs diff fcl > fcl.diff

Hmm, if I understand you right then this command will produce a diff of
all files in the fcl tree?

What I wanted is a diff of e.g. classes.pp for Win32 vs. for Linux.
Similar to a diff of classes.pp (FPC) vs. classes.pas (D4).


> Having nested ifdefs with matching endifs or elsifs several hundred
> lines further _is_ a hell if you didn't write the code.

It's a hell even if you wrote such code yourself :-(


> If you have projects were a _team_ works on, having multiple include
> files is definitively better.

I'm not sure. The organization has nothing to do with contents. A
version control system always has to handle concurrent updates of the
same pieces of text, regardless of the size and number of the related
files. It were most important to me to find related changes, in all
affected places, based on a single change notice. Yes, I know that I can
grep all possibly affected files for a common change notice, but that is
not what I need and want to have.

I agree that include files help to keep distinct contents in distinct
places. But development means to fit things together, so that
dependencies and relationships must be recognizable in the first place.

> When fixing bug by bug in 10min you don't think about better log messages :)

I don't remember the exact procedures, isn't it required to connect to
the server for such updates? For me that would mean to boot a different
OS, connect to the server, synchronize with cvs, shut down and reboot my
working OS again. Even without a reboot such a sync (update?) breaks the
workflow, and I started to use an batch file with the messages and the
related units. AFAIR not a pleasant procedure at all, and a sync usually
took more than 10 minutes :-(

Bug fixing is not the primary goal of development. Even if I agree that
bug fixing is inevitable, I suspect that the relationship between bug
prevention and bug production is tightly related to the used development
tools and methods. But that's another story...

DoDi