I am testing an old Delphi communications component with lazarus. I don't want to install it as a component but instead create it in code. So I have started a new project and added the path to the Serial unit to the project options (Other Unit files).
I also included it in the uses clause.

In my form I have put code to create it and set its properties like this:

procedure TForm1.FormCreate(Sender: TObject);
begin
  serComm := TSerial.Create(NIL);
end;
procedure TForm1.btnOpenClick(Sender: TObject);
begin
  serComm.Baudrate := 38400;
  serComm.DataBits := d8bit;
  serComm.StopBits := st1bit;
  serComm.FlowMode := fcNone;
  serComm.Port := 1;
  serComm.Active := true;
end;

When I did this lazarus showed me hints on what I could select when I added the period after the serComm name, so I know that it is known by lazarus.
But when I try to run the program lazarus shows an error:

unit1.pas(22,21) Error: Identifier not found "TSerial"

But TSerial is the class name for the component and it is found by lazarus when I write the code, so why in heavens name does it not find it when compiling???????

Bo Berglund

First, one thing I can say about the fpc is that it is a pretty solid piece of code. Yes, it does have some different quirks with delphi (overloading for example), but in over 1,000,000 lines of code I have personally compiled I have not (recently) found even one instance where it was a bug related to the fpc. Meaning, I always start off by questioning what I did wrong first before blaming the compiler. That is just me, though... Now on to your question...

It sounds like it fpc parser does not like your class file name for some reason. This is just a guess, however without looking at an strace output. Try several things... First, remove the file and see if it complains. If that does not work, baby step it by creating a new file with a different class name... If you still cannot figure it out, then send the files to and I will see what happened.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110210/3c42e23f/attachment-0001.html>

Op 2011-02-11 00:41, Bo Berglund het geskryf:

But TSerial is the class name for the component and it is found by lazarus when I write the code, so why in heavens name does it not find it when compiling???????

As far as I know Lazarus uses CodeTools for code navigation - that is different to the information used by the compiler (FPC) to compile your project.

Select "Project -> Project Options -> Show Options" and have a look an see if the path is indeed supplied and or correct, so FPC can find the unit TSerial component resides in.

Regards,
- Graeme -

Do you have units with upper case letters in the file name? Maybe you have two units with the same name.
Go to your uses section, where Serial is uses. Place source editor cursor at the end of the used unit name and use Ctrl+Space to fix the case.

Mattias

I just got the same error.
The cause was a cross unit reference. Implementation uses sections are evil. It's near impossible to create simple bug reports for such compiler bugs.

Mattias

Thanks, but this is my options:

-MObjFPC -Scghi -O1 -gl -WG -vewnhi -l -Filib\i386-win32 -FuC:\Engineering\Projects\Lazarus\cmp\Serial
-FuC:\Programs\lazarus_0_9_30_fixes\lcl\units\i386-win32 -FuC:\Programs\lazarus_0_9_30_fixes\lcl\units\i386-win32\win32 -FuC:\Programs\lazarus_0_9_30_fixes\packager\units\i386-win32 -Fu. -FUlib\i386-win32\ -oproject1.exe -dLCL -dLCLwin32

Notice the second line....
That is where the Serial.pas file resides and where it is picked up by the IDE.

Now I tried to enter the path to this dir in the project options for "Other sources" instead, but the compile error is exactly the same. The file is named Serial.pas and it contains amongst others this:

unit Serial;
...
interface

uses
SysUtils, WinTypes, WinProcs, Messages, Classes, Graphics, Controls,

  Forms, Dialogs,Windows;

type
...
{ TSerial main class }

  TSerial = class(TComponent)
  private

etc

Do I need to add some kind of switch telling FPC that this file originated in Delphi? I seem to recall that there is such a marker, but I don't know what it looks like.

Bo Berglund

Ther unit file is Serial.pas
There is no other file named like this in any case style.

What I did was to go to the uses clause put the cursor on the word Serial and use the pop-up menu command "Open file at cursor", which brought the file into the editor...
Ctrl-Space does nothing other than pop up a window with three names, the top being Serial.

Bo Berglund

Maybe
fpc/rtl/unix/serial.pp

I get only one. The one from fpc.

Compile with -vt and see if fpc loads the right unit. If yes, check for implementation uses sections. Maybe you have the fpc bug I wrote in the other mail.

Mattias

Bo Berglund wrote

unit1.pas(22,21) Error: Identifier not found "TSerial"

I finally managed to get my file recognized by *both* lazarus and fpc. This is how:

1) In project inspector I *added* the Serial.pas file to the project.

2) In the Serial.pas file I added the following conditionals:
At the top of the file:
{$ifdef fpc}
  {$mode delphi}
{$endif}

further down I had to remove two uses files:
uses
SysUtils,

  {$ifndef fpc}
  WinTypes,
  WinProcs,
  {$endif}

Now the test project compiles all right, but unfortunately it does not work and I don't know if this is caused by:
- My PC has only one real serial port (in the docking station) so all others are via USB adapters.
- Some confusion caused by VMWare in my virtual machine when mapping com ports.
- My own shortcomings in using lazarus/fpc

I even copied the test program exe file over to my host and tried to communicate via the serial ports to a Hyperterminal running on the host using a null-modem cable between the real com port and one of the USB ones. No go....
So this test with my old and proven Delphi serial component seems not to work out, and it would not have sufficed anyways because I need cross-platform compilation.

In any case right now I have only one working configuration for the real project I am working on:
- Development in the virtual machine (no lazarus/FPC on the physical laptop)
- Program uses COM1 in the virtual machine
- VMWare maps virtual machine COM1 to host COM1 (the real port)
- The other end of the connection is a simulator I am always using when developing stuff and it connects to one of the USB ports (the ATEN one is the only one working).

Seems to be a real bugger to get serial ports working properly and I cannot rule out my laptop itself either. I got it in December and it has Win7x64 whereas I always used WinXP-Pro for the last 8-9 years or so. Maybe the Windows drivers are not up to speed? The SUNIX device uses the Prolific serial converter chip and driver. I think that basically it is a 4-way USB hub followed by 4 individual Prolific RS232 converters in one box.

Has anyone here successfully used SdpoSerial in lazarus on Win7x64 towards a SUNIX ComHub 4-channel adapter???

Bo Berglund

Op 2011-02-11 19:29, Bo Berglund het geskryf:

Notice the second line.... That is where the Serial.pas file resides and where it is picked up by the IDE.

Umm, then I have no clue, sorry.

unit Serial;

  {$IFDEF FPC}
    {$mode delphi}{$H+}
  {$ENDIF}

Normally you would add the code shown above (below the 'unit' line).

Regards,
- Graeme -

Could you expand on this?

I am used to my Delphi practice of putting uses references as far down the ladder as possible.
This means that if something is not needed in the interface section I routinely put it into the implementation uses.

Is this bad practice with FPC/Lazarus?

... with another unit and identifier.

The general idea is a good one, because this could help to avoid unneeded/accidental dependencies in the interface. OTOH I never got that case in reality, so I wonder if this really helps someone.
For the program size or unit dependencies it does not matter if the unit is used in the implementation or the interface. The implementation uses section has some disadvantages:
1. It can redefine types. For example using the Windows unit redefines TRect.
2. You can create "circular" dependencies without noticing. 2.1 Circular dependencies make it hard to tell the order of initialization sections.
2.2 Combined with some optimization features the compiler has to recompile some units multiple times. Since I know FPC this process had bugs, resulting in strange errors. The FPC team did a great job to fix all they could reproduce. The problem is that the remaining bugs happen only in big programs and it is near impossible to create a small example, so these bugs are not reported and therefore not fixed.
2.3 Circular dependencies make refactoring a lot harder.
3. The uses section is split, reducing readability.

Conclusion: I don't see any real advantage but I see some disadvantages, so I recommend to avoid the implementation uses section whenever possible.

Mattias

IMO this applies to bugreports (only). The unit order in uses clauses is always important, regardless of one or two such clauses.

FPC can have some problems with macros, inlines and other constructs, that may require a recompilation of units. But apart from that (acceptable) issue I don't see real obstacles right now.

DoDi

Mattias Gaertner wrote

1. It can redefine types. For example using the Windows unit redefines TRect.

On a half-related note, I think FPC would strongly benefit from Python-like "limited import" feature.
Quote from http://docs.python.org/tutorial/modules.html#more-on-modules : "Note that in general the practice of importing * from a module or package is frowned upon, since it often causes poorly readable code. "

2. You can create "circular" dependencies without noticing. 2.1 Circular dependencies make it hard to tell the order of initialization sections.

...

2.3 Circular dependencies make refactoring a lot harder.

I still believe that a simple warning from FPC would go a long way to fixing this problem.

3. The uses section is split, reducing readability.

I personally find the opposite -- if properly maintained, the separate "uses" lists are giving reader additional information about unit dependencies and at the same time reduce the amount of dependencies one must scan in order to understand only the unit interface (i. e. to use, not develop, a unit).

I also find the opposite.

Using a unit in a uses clause defines the scope of the usage. I think the overriding principle should be to limit the scope to only the code that requires it. Using a unit in the implementation section adds valuable info to the reader that the used unit is NOT needed to define the current unit's interface.

Readability is mostly up to what you are used to. That's why I listed it as advantage and disadvantage.
The implementation uses section does not make the code more readable for everyone. IMHO comments are better suited for that.

It is not the first time that people added implementation uses sections to the Lazarus code, creating circular dependencies, which lead weeks/months later to strange errors. And since I'm often the one who has to fix it I call the implementation uses sections "evil" and I hope that people will use them only when needed and not only for "readability".

Mattias

The implementation uses section does not make the code more readable for everyone.

It makes the *interface* section more readable.

IMHO comments are better suited for that.

Did you ever see a uses clause, separated by comments into units required by the interface and the implementation?

That would be useless because nobody can verify that distinction, without actually moving the units into the implementation uses and compile again.

DoDi

Not for everyone.
Some people read the uses sections only to find out what is needed to compile the unit.

> IMHO comments are better suited for that. Did you ever see a uses clause, separated by comments into units required by the interface and the implementation?

No.
Apparently those who care separate them and those who don't care, see no reason to mention it.

That would be useless because nobody can verify that distinction, without actually moving the units into the implementation uses and compile again.

What about class private members? You don't need them to understand the interface, but you might need some extra units for them.

Apparently I'm too stupid to understand the gain of the readability of uses section separation, but I know the trouble with FPC.

Mattias

Op 2011-02-19 16:11, Bo Berglund het geskryf:

Is this bad practice with FPC/Lazarus?

I don't think so. At least in my FPC-base programs I have always preferred putting things first in the implementation uses clause before the interface uses clause. As the old design statement goes.... On make things public when really needed.

Contrary to Mattias statement - this reduces circular unit references in my case/applications. I could never understand how Mattias thinks otherwise.

Regards,
- Graeme -

Op 2011-02-19 17:03, Mattias Gaertner het geskryf:

3. The uses section is split, reducing readability.

I've never found that an issue, or ever heard any programmer complain about that - so it's probably your own preference. After all, the whole unit is split in two section. ;-)

disadvantages, so I recommend to avoid the implementation uses section whenever possible.

This makes no sense - yet again. I have only ever seen this statement being used in the Lazarus IDE project - nowhere else. In my experience (just like in Delphi) it reduces circular unit dependencies if you use the implementation section as much as possible, before the interface uses section.

Regards,
- Graeme -

Op 2011-02-19 18:47, Mattias Gaertner het geskryf:

It is not the first time that people added implementation uses sections to the Lazarus code, creating circular dependencies, which lead weeks/months later to strange errors.

I have yet to see such an example - and least this has never happened in my years of working with Object Pascal, Delphi, FPC. Lazarus IDE is the only project I have ever heard of such problems so....

1) There is something really strange about the Lazarus IDE code

2) If you think the implementation section causes circular unit reference issues, then it is contrary to how Delphi explains the object pascal language - thus there is a bug in FPC, because Delphi does not work like that. Please report such a issue with an example to the FPC team please. I would be very interested in such an example too.

Regards,
- Graeme -

The problem is that FPC often crashes while compiling a project with complex implementation uses relations. Compiling with -B normally fixes the issues. A testcase must contain the whole project with the existing ppu's.

Martin

Op 2011-02-21 09:12, Martin Schreiber het geskryf:

The problem is that FPC often crashes while compiling a project with complex implementation uses relations. Compiling with -B normally fixes the issues. A testcase must contain the whole project with the existing ppu's.

That again tells be that it is NOT a language issue (interface vs implementation uses clause), but rather a FPC bug.. FPC failing to managing uses clauses relationships, or problems detected changed units with existing ppu's etc...

So telling people to change the programming language or programming style, just because of a FPC bug doesn't bode well. Rather fix the cause of the problem.

Regards,
- Graeme -

In my past Delphi experience I was hit by circular references when placing my own units in the interface uses so I moved them to the implementation uses.
Ever since then I have refrained from putting anything into Interface uses that is not explicitly needed by stuff in the interface. Has worked fine in all versions of Delphi that I have used (all from D1-D7 and then BDS2006 too).

You can't create circular dependencies with only interface dependencies. Only implementation uses section allow this.

Mattias

Graeme Geldenhuys wrote

it reduces circular unit dependencies if you use the implementation section as much as possible,

How? Dependency is dependency. The danger of putting units in the implementation uses clause is that somebody creates circular dependencies by accident. This cannot happen when the unit is used in the interface part. This is usually a no brainer for small teams and projects but for bigger projects it might matter.

Op 2011-02-21 09:41, Mattias Gaertner het geskryf:

You can't create circular dependencies with only interface dependencies. Only implementation uses section allow this.

Really? See attached project. Took me all of 30 seconds to create such an example for you. Only Interface uses sections are used.

Regards,
- Graeme -

Graeme Geldenhuys wrote

just because of a FPC bug doesn't bode well. Rather fix the cause of the problem.

It is a known issue for years that FPC gets rarely into trouble with complex circular unit dependencies. The problem is the recursive design of the unit loader. However, nobody volounteered yet to fix it :(

Op 2011-02-21 09:50, Graeme Geldenhuys het geskryf:

And just to be clear...by that I mean, to get the "circular unit reference error" in FPC. So simply using Interfaces uses section only doesn't resolve such an issue.

Yes it is a crap example, but I have seen much more complex code where dependencies are required, and the only way to get that code to compile, was to move some units to the implementation section, or use the Interfaces language feature.

Regards,
- Graeme -

And? Does it compile?

Of course it does: a similiar project using the units only in the implementation part compiles.

Op 2011-02-21 09:36, Bo Berglund het geskryf:

That's my exact experience too, using Delphi, Kylix and FPC. And that is the point I was trying to make with my original post, but it seems Mattias thinks otherwise. :)

Regards,
- Graeme -

Op 2011-02-21 09:55, Florian Klaempfl het geskryf:

And? Does it compile?

Read Bo Berglund's message from a few minutes ago... maybe he explains better what I was trying to get at.

Regards,
- Graeme -

That's what I mean.
Using the interface uses section, the compiler does not allow circular dependencies. Moving it into the implementation section keeps the circle between the units. I don't know if Delphi has no problems with it, but FPC has some problems. They became smaller from year to year, which is why the Lazarus code already uses them at a few places. The problem does not appear immediately. This time it appeared several months after adding a circle.
Breaking the circle also created a cleaner design. IMO cleaner design is pov, just as "readability", which is a signal word for some developers and for some trolls as well.

Mattias

Well, he got it wrong :) It is exactly the point of putting units in the interface uses clause: the compiler helps you to avoid circular unit dependencies. When you put them in the implementation clause, you just hide them, they are still here but the compiler does not complain as long as you don't hit its flawed unit loading algorithm.

D7 sometimes has problems with uses resolution too. With Delphi -B does not help always, sometimes it is necessary to compile a second time...

Martin

So, Florian, how about adding a compiler hint or warning for circular dependencies?
Maybe off by default, to avoid compatibility issues? I would definitely use such a hint in all my projects.

I'am not sure if the compiler somewhere gets this information explicitly. As said, the design of the unit loading is fundamentally flawed.

In our code at work I'm currently often archieving this with Delphi: Sometimes I change a bit in the implementation section of one of our core components (you don't want to know what a "big thing that does everything" that is... :( ) and when compiling the package Delphi claims that the unit references itself. I have not yet checked whether this is really the case (huge uses clauses... maybe I should use a tool that plots a nice graph of used units ^^), but compiling a second time usually solves this issue.

Regards,
Sven

Contrary to Mattias statement - this reduces circular unit references in my case/applications. I could never understand how Mattias thinks otherwise.

Mattias obviously separates allowed (effective) circular unit references from disallowed (interface) references. Problems only can arise from allowed references, the disallowed ones just don't compile and need no further considerations.

Sadly it's true that FPC has problems with re-using units, a few weeks ago I still had to patch the compiler for properly retrieving already compiled units, so that loops can be detected and broken up when an already compiled (and cached) unit is used again. But I don't think that it matters whether a unit is re-used in the interface or implementation section, since both cases are handled in the same code.

DoDi

It is a known issue for years that FPC gets rarely into trouble with complex circular unit dependencies. The problem is the recursive design of the unit loader. However, nobody volounteered yet to fix it :(

Volunteered yes, but not accepted :-(

The main problem I spotted is not the recursive loading, but the retrieval of cached units. A related problem are all the global variables, that are not always updated in sync. This can lead to different "opinions", about compiled ppu modules and their source files, or about recompile reasons and state.

The pragma "FPC is an production compiler" effectively disallows to introduce safe (OO...) methods into the compiler code, so that we'll have to live forever with obscure compiler bugs :-(

DoDi

So, Florian, how about adding a compiler hint or warning for circular dependencies?

Circular unit references occur in most real-life code, so that according hints are quite useless. If ever, such a feature should at least allow to suppress warnings about well known and unbreakable loops. But even then the compiler cannot give useful hints, about *where* unwanted loops can be broken up.

The only really useful feature is the detection of unneeded unit references, and this feature already exists: Editor context menu -> Refactoring -> Show unused units.

DoDi

So do, e. g. unused paramaters. This is why I proposed a hint, not an error. That said, I really believe that any circular unit dependency is a (design) bug.

If ever, such a feature should at least allow to suppress warnings about well known and unbreakable loops.

Sure. I have even suggested the warning to be disabled by default.

Anyway, it seems that there is no chance of this happening in FPC. Maybe if you at last create your own fork ;-)

Op 2011-02-21 22:14, Sven Barth het geskryf:

In our code at work I'm currently often archieving this with Delphi:

So the problem is not only limited to FPC.

plots a nice graph of used units ^^), but compiling a second time usually solves this issue.

Exactly.... and that means the code is valid syntax (otherwise it would never have compiled at all), but the compiler gets confused. The problem sits with the compiler, not the code. This is what I was trying to get across to Mattias and his example of the Lazarus IDE project. No point in recommending all developers changes their style of coding, when the issue is in the compiler - not the language. Rather try and fix the cause of the problem, not the symptom.

Regards,
- Graeme -

In general you are right.
But I'm afraid, it is not that simple in this case. I know it is hopeless to tell you, but the bug is known, is hard to reproduce and as Florian wrote it is a design flaw, so fixing is very hard and there are other priorities. And even if it is fixed the fix won't be in the released compiler.
And in the last appearance of the bug the circular unit dependency was IMHO bad design and is now better solved by a hook. Showing some help should not require direct access to the help editor. In my experience circular dependencies are often bad design. In fact the only good reason for them I know is compatibility.

Mattias

I do know that Delphi doesn't inline functions between (any) mutually dependant units.

Graeme Geldenhuys wrote

No point in recommending all developers changes their style of coding, when the issue is in the compiler - not the language. Rather try and fix

Feel free to do so, we are all waiting for at least five years for somebody to fix it :) I estimate that it takes me on month of fulltime work to fix it by rewriting the whole unit loading mechanism. I simply don't have the time to do and it seems nobody else either.

the cause of the problem, not the symptom.

If you can't heal a disease, you can at least try to reduce the symptoms.

Op 2011-02-22 11:27, Florian Klaempfl het geskryf:

Feel free to do so, we are all waiting for at least five years for

Wasn't that what Hans-Peter (or somebody) recently tried?? But from the discussions I read, the changes were "to radical" from a non-core member, so as usual, the changes get declined.... or core-members keep arguing every little step until they discourage the developers from even trying to contribute.

So I'll limit my contributions to documentation tools and the FCL, or in the case of RTL or compiler features - to a fork of FPC... there are much less resistance that way. Sad, but true. I'm not wasting your time, and you are not wasting my time.

Regards,
- Graeme -

Please stay with the truth: first of all, the proposed changes so far had nothing to do with improving unit loading. Further, none of the changes were working. You'd kill me, if I merged those changes breaking FPC completely :)

Last but not least: the radical changes (also far from working changes in the sense of no regressions) which get declined aimed on a multi language front end for FPC. While this in theory is imaginable, I expect a lot of dedication before I merge such changes into FPC: it means not only a hacked parser, but also a complete new runtime environment, complete reorganisation of the directory structures and build processes, a lot of new regression tests etc. Considering
http://fpcext.git.sourceforge.net/git/gitweb.cgi?p=fpcext/compiler;a=summary the dedication and interest is little.

That said, I really believe that any circular unit dependency is a (design) bug.

Ah, that's why the FPC compiler is so buggy ;-)

Tools to analyze unit references exist already :-)

Maybe if you at last create your own fork ;-)

I've already created such a fork: SourceForge.FpcExt :-)

Unfortunately the new SF interface seems to be broken a bit, so that I cannot delete the old (usesless) repository, and cannot show the two repositories for the compiler and documentation :-(

It also is hard to keep that compiler in sync with the trunk, when so many parts are moved into other units.

Currently I try to fix the most annoying bugs and flaws in the Lazarus IDE, so that I can use it as I like it. And in the documentation and help tools, that is in desastrous state :-(
Having done that, I may resume my work on FPC...

DoDi

You'll hardly find anybody, to fix these bugs at *your* (FPC team) conditions :-(

I estimate that it takes me on month of fulltime work to fix it by rewriting the whole unit loading mechanism. I simply don't have the time to do and it seems nobody else either.

I have the time, and already spent many months with the compiler flaws. But it turned out to be Sysiphus work, when a completed fix is rejected for almost formal reasons :-(

> the > cause of the problem, not the symptom. If you can't heal a disease, you can at least try to reduce the symptoms.

It's not a matter of ability, instead it turned out to be a matter of policy, only :-(

DoDi

The bugs do not necessarily reside whery *you* expect them. This is one reason that blocks efficient bug fixes.

Further, none of the changes were working. You'd kill me, if I merged those changes breaking FPC completely :)

Please stay with the truth: all but the very first (OO) branch have been tested thoroughly, and I couldn't find any breaks.

Last but not least: the radical changes (also far from working changes in the sense of no regressions) which get declined aimed on a multi language front end for FPC.

This is only one *possible* feature, a side effect of an attempt to allow for parallel compilation.

Bullshit :-(
[Sorry for the harsh wording, but it is so]

Considering http://fpcext.git.sourceforge.net/git/gitweb.cgi?p=fpcext/compiler;a=summary the dedication and interest is little.

I already outlined why I suspended working on that project, until the SF interface becomes usable.

DoDi

Hans-Peter Diettrich wrote

when a completed fix is rejected for almost formal reasons :-(

Which of your prototypes do you call fix? What does it fix? Did you ever post regression test results?

I already outlined why I suspended working on that project, until the SF interface becomes usable.

ROFL This statement says enough I think.

Hans-Peter Diettrich wrote

Please stay with the truth: all but the very first (OO) branch have been tested thoroughly, and I couldn't find any breaks.

Before anybody wonders what "I couldn't find any breaks" means:

make all

for the NoGlobals branch results in

make[7]: Entering directory `c:/fpc/branches/NoGlobals/rtl/win32' c:/fpc/branches/NoGlobals/compiler/ppc1.exe -Ur -Xs -O2 -n -Fi../inc -Fi../i386 -Fi../win -FE. -FUc:/fpc/branches/NoGlobals/rtl/un its/i386-win32 -di386 -dRELEASE -Us -Sg system.pp -Fi../win c:/fpc/branches/NoGlobals/compiler/ppc1.exe -Ur -Xs -O2 -n -Fi../inc -Fi../i386 -Fi../win -FE. -FUc:/fpc/branches/NoGlobals/rtl/un its/i386-win32 -di386 -dRELEASE -I../objpas ../objpas/objpas.pp Fatal: Can't find unit fpintres used by objpas
Fatal: Compilation aborted
make[7]: *** [objpas.ppu] Error 1
make[7]: Leaving directory `c:/fpc/branches/NoGlobals/rtl/win32' make[6]: *** [win32_all] Error 2
make[6]: Leaving directory `c:/fpc/branches/NoGlobals/rtl' make[5]: *** [rtl] Error 2
make[5]: Leaving directory `c:/fpc/branches/NoGlobals/compiler' make[4]: *** [next] Error 2
make[4]: Leaving directory `c:/fpc/branches/NoGlobals/compiler' make[3]: *** [ppc2.exe] Error 2
make[3]: Leaving directory `c:/fpc/branches/NoGlobals/compiler' make[2]: *** [cycle] Error 2
make[2]: Leaving directory `c:/fpc/branches/NoGlobals/compiler' make[1]: *** [compiler_cycle] Error 2
make[1]: Leaving directory `c:/fpc/branches/NoGlobals' make: *** [build-stamp.i386-win32] Error 2

c:\fpc\branches\NoGlobals>svn info
Path: .
URL: http://svn.freepascal.org/svn/fpc/branches/dodi/NoGlobals Repository Root: http://svn.freepascal.org/svn/fpc Repository UUID: 3ad0048d-3df7-0310-abae-a5850022a9f2 Revision: 16976
Node Kind: directory
Schedule: normal
Last Changed Author: dodi
Last Changed Rev: 15959
Last Changed Date: 2010-09-09 14:38:14 +0200 (Do, 09 Sep 2010)

Granted, that branch also was not tested as it should have been. Instructions on how to test the compiler had been given very late :-(

DoDi

Without the conditions, you only get redesigners, not bugfixers.