[fpc-devel] property syntax extension

Mattias Gaertner nc-gaertnma at netcologne.de
Sun Oct 21 13:58:01 CEST 2007


On Sun, 21 Oct 2007 01:43:51 +0200 (CEST)
Michael Van Canneyt <michael at freepascal.org> wrote:

> 
> 
> On Sun, 21 Oct 2007, Mattias Gaertner wrote:
> 
> > On Sun, 21 Oct 2007 00:46:19 +0200 (CEST)
> > Michael Van Canneyt <michael at freepascal.org> wrote:
> > 
> > > 
> > > 
> > > On Sat, 20 Oct 2007, Mattias Gaertner wrote:
> > > 
> > > > On Sat, 20 Oct 2007 16:29:40 +0200
> > > > "Tomas Hajny" <XHajT03 at mbox.vol.cz> wrote:
> > > > 
> > > > > On 19 Oct 07, at 13:14, Micha Nelissen wrote:
> > > > > > Jonas Maebe wrote:
> > > > > > > This is not true. You can perfectly compile a compiler
> > > > > > > using the previous' release rtl. 
> > > > > > 
> > > > > > Sure this is not the question.
> > > > > > 
> > > > > > > E.g. the people developing using the fp IDE often 
> > > > > > > do this (because they have a project for the compiler, but
> > > > > > > that one does not automatically compile the rtl). 
> > > > > > 
> > > > > > Adapt the project to use the new RTL ? Anyway, seems
> > > > > > "dangerous" to me, not testing possible RTL regressions
> > > > > > then.
> > > > > > 
> > > > > > > A while ago, Peter removed several 
> > > > > > > dependencies of the compiler on the new rtl (related to
> > > > > > > endian swapping routines) for this reason.
> > > > > > 
> > > > > > I see the reason is not really coming out, but I'll stop
> > > > > > now.
> > > > > 
> > > > > Well, I'd certainly have one (more) reason not to 
> > > > > put it into RTL - I don't think that support for 
> > > > > .ppu file format is something so general and 
> > > > > commonly used by (Free) Pascal programmers that 
> > > > > it should become part of our RTL.
> > > > 
> > > > And another:
> > > > A lazarus built with fpc 2.0.4 should be able to read the ppu of
> > > > 2.3.x. Even though the ppu format is very stable, it is not
> > > > carved in stone.
> > > 
> > > It's built so that a newer version can always read an older PPU
> > > file and vice versa: an old ppu unit can read a newer file, but
> > > just doesn't know how to interpret certain blocks.
> > 
> > Are we talking about a complete ppu parser or something to only read
> > the property info?
> 
> Well, the ppu file is divided in blocks; Each block has a type and a 
> size. If you don't "know" a block, you can 'skip' it.
> (If memory serves me right, of course)

If the codetools can only read those fields of the ppu, that are
supported by the fpc version used for building the codetools, then the
ppu reader will always stay merely a fallback parser - only used if
there are no sources or to check the user configuration.

In this case: The property information can not be read with the
released fpc 2.2. And this means probably the next years.

IMHO the codetools should be able to read the ppu of all available fpc
versions, independent of the fpc used compiling the codetools.


> > > > So, maybe it would be best to keep a working copy of the ppu
> > > > reader unit in the lazarus svn and give it a distinct name?
> > > 
> > > I think such a unit could best go in the packages, since it is
> > > tightly bound to FPC, and definitely non-visual ? 
> > 
> > Well, it should be bound to FPC, but it should not be bound to a
> > specific FPC version.
> 
> Exactly. That's why we need a copy. The copy (ppuparser or whatever)
> can maintain knowledge of past versions, as far as that is needed.


Mattias



More information about the fpc-devel mailing list