> > fixed in between. However, you'll probably have to start cycling
> > with a 1.0.10 compiler. This is a general rule - if cycling
> > doesn't work with the snapshot, try to start with the latest
> > official _release_ version (not beta!) - this rule should be
> > added to the build FAQ probably.
It is in the buildfaq, with a rationale even, and probably also in the
normal faq. It's a rule that is with FPC as long as I'm a part of it.
> I don't want to critize you, but I think, a 1.9.3 should be able to compile
> a newer 1.9.3. If not, then it's time to increase the version number.
That's not how FPC versioning works, and is also not sane for a compiler
There is an infinite range of 1.9.3 versions, and incompabilities between
them can be very small, but the differences from versions near 1.9.3 are
gradually increasing going from 1.9.2 to 1.9.4. We would go up in version
faster than the avg Linux distro!
On the other hand, the release compiler's problems and peculiarities are
more wellknown.
There is a paragraph about FPC versioning in the FAQ
> In this case the rtl/unix/dos.pp contains some lines, that look suspicious
> to me:
> {$ifdef HASTHREADVAR}
> {$ifdef VER1_9_2}
> var
> {$else VER1_9_2}
> threadvar
> {$endif VER1_9_2}
> {$else HASTHREADVAR}
> var
> {$endif HASTHREADVAR}
The 1.9 beta's (1.9 and 1.9.2) are somewhat special. They are not formal
releases, but are quite stable. Maybe one of the later 1.9.x beta's will be
rubberstamped "release", to replace 1.0.10 as starting compiler. This would
allow to remove 1.0.x startingcompiler support from the codebase.
_______________________________________________
fpc-pascal maillist - [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
