[fpc-devel] Portability Standards
F.Klaempfl at gmx.de
Tue Jan 4 11:36:49 CET 2005
> Florian Klaempfl wrote:
>>Not everything is a matter of OS. It could be also a matter of toolkit,
>>database, word size of the cpu or whatever. Further smaller files are
>>usually easier to handle:
>>- cvs works much better with small files
>>- 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.
> 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 :)
> 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.
> 4) Long search pathes require accordingly featured tools (target
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
>>- last but not least: work with small units as much as possible
> I think that I prefer compact projects, with few units and no include
Having nested ifdefs with matching endifs or elsifs several hundred
lines further _is_ a hell if you didn't write the code.
> At least I don't like units consisting effectively only of includes.
> That's near C, with it's sea of header files and unrelated
> implementation modules, and the effectively compiled text becomes
> visible only after running the preprocessor :-(
If you have projects were a _team_ works on, having multiple include
files is definitively better.
> BTW, I already wrote an preprocessor to produce single files from the
> FPC units. Now I have to extend it, for multiple targets...
>>- easier overview what has been modified when checking logs: which log
>>entry is better:
>> rtl/system.pp: fixed writeln
>> rtl/morphos/ossysc.inc: fixed writeln
> I'm not sure about the logging conventions. Precise logs require to save
> almost every single change, with an appropriate comment. After half an
> hour with multiple related corrections it's hard to find a really
> descriptive common subject.
When fixing bug by bug in 10min you don't think about better log messages :)
More information about the fpc-devel