New Indy10_4620 of April 11, 2011 works in Lazarus

[JD]

With the help of Remy Lebeau (one of the Indy crew), I was able to install the new Indy10 in Lazarus.

This installation process worked for Lazarus 0.9.31 FPC 2.4.3 SVN 30042 on Windows XP & Vista.

a) First download the most recent Indy10 version from
http://indy.fulgan.com/ZIP/
b) Unzip the file
c) Go to the \Lib directory
d) Copy the *.pas, *.lrs and *.inc of the \System, \Core, and \Protocols subdirectories into a new directory of your choosing. Remy Lebeau said the source files must be in the SAME directory. Delphi does not have this constraint but hey, I'm not complaining.
e) Copy the indylaz.lpk in the main directory of the zip file to the directory you created in (d) above
(f) Start Lazarus & open the package file in (e) above
(g) In the package options dialog, add the path to the directory you created in (d) above to the "Unit" field
Mine looks like this "$(LazarusDir)\components_extra\Indy10_4620"
(h) Compile & install the package
(i) If all goes well; you'll have all 16 Indy tabs visible in the Lazarus IDE   

In order to write & compile Indy10 applications, you need to put the path to the Indy directory in the "Other Unit files" textbox of every project that you write. You'll find "Other Unit files" under Project Options -> Compiler Options -> Paths.

For good measure, I kept the directory where I unpacked the old Indy 10.0.5 for Lazarus. That way even though I installed the new Indy10 in my IDE, I can still compile & run my old Indy 10.0.5 programs by entering the path to the old Indy 10.0.5 directory in the "Other Unit files" textbox.

I hope you'll find this helpful.

JD

[marcov]

One could try to just remove the redundant versions of the various .inc files. Mostly notably idcompilerdefines.inc

With that change, I can compile it easily. I've notified indy-core about that several times in the last two years.

That's probably also why the packages must be in a separate dir. Then they have the same order of
directory inclusion, and then it just happens to work because all packages find the same .inc.

The multiple includefile situation is known (and considered intended behaviour), and considered a bug in Delphi that it allows it.

[JD]

One could try to just remove the redundant versions of the various .inc files. Mostly notably idcompilerdefines.inc

With that change, I can compile it easily. I've notified indy-core about that several times in the last two years.

That's probably also why the packages must be in a separate dir. Then they have the same order of
directory inclusion, and then it just happens to work because all packages find the same .inc.

The multiple includefile situation is known (and considered intended behaviour), and considered a bug in Delphi that it allows it.

You're right. I noticed the redundant *.inc files also. I just didn't know that it was done because of a bug in Delphi.

All Remy told me was to put the files in the same directory. I had to figure the rest out through trial & error until I was able to compile & install it. 

Anyway, I'm really glad to have the same Indy versions in my Delphi & Lazarus installations. I intend to update them simultaneously in future so that one version does not fall far behind the other.

[marcov]

One could try to just remove the redundant versions of the various .inc files. Mostly notably idcompilerdefines.inc

With that change, I can compile it easily. I've notified indy-core about that several times in the last two years.

That's probably also why the packages must be in a separate dir. Then they have the same order of
directory inclusion, and then it just happens to work because all packages find the same .inc.

 That should have been find the same .inc *first*.

The multiple includefile situation is known (and considered intended behaviour), and considered a bug in Delphi that it allows it.

You're right. I noticed the redundant *.inc files also. I just didn't know that it was done because of a bug in Delphi.

Now I must be careful to not increase confusion. Let me explain exactly what is going on.

1) Delphi does NOT automatically recompile on .inc change. If you change an .inc you have to force a build.
2) FPC DOES recompile on an .inc change and knows which unit is compiled with which .inc by storing data (IIRC CRC and datestamp) in the .ppu
     -> this leads to havoc with multiple .inc files with the same name.
3) FPC does so since before it had Delphi compatibility, and it is ingrained in our buildsystem. Nothing we can do even mid-long term.

I've communicated several times with Indy, and sometimes they say it works for them.

It might actually occasionalyl work with FPC, but only if the files are exactly the same and probably with the same date. So if somehow dates gets messed up while unzipping or other packaging/decompression activities, a supposedly working package can become non working again.  Even fractions of a second (that are not visible in explorer) might be enough to mess up building. IOW the time between decompressing the first and last file with the same name

All it takes to solve this is moving the includefiles to some common directory. System or a new "include" directory.

At least for the ordinary compiling part. I haven't seen the design parts working since the unicode branch started (and was later merged back to trunk)

All Remy told me was to put the files in the same directory. I had to figure the rest out through trial & error until I was able to compile & install it.  

That is because that is their plan anyway for Indy11. (hopefully together with killing that dreadful TIdBytes hack). But that doesn't mean it is the easiest way for the current situation.

Anyway, I'm really glad to have the same Indy versions in my Delphi & Lazarus installations. I intend to update them simultaneously in future so that one version does not fall far behind the other.

I'm glad that desgintime is working again, and will do my own tests if I have time. Now we also need to get parts updated to the new FPC 2.4/0.9.30 resource system (and getting rid of .lrs and using RES files)

[JD]

@marcov
OK. It's much clearer now thanks.

I'm glad that desgintime is working again, and will do my own tests if I have time. Now we also need to get parts updated to the new FPC 2.4/0.9.30 resource system (and getting rid of .lrs and using RES files)

The sooner the better. BTW maybe it is time to update the Lazarus Wiki concerning the availability of a more recent Indy version. I say this because when I had some problems with Indy 10.0.5, I was told that it was too old & that I should upgrade because some of the code had been deprecated.

[thierrybo]

The last time I tested (09/2010), I succeeded to compile and use 10.5.8 (latest at this time). However it was not working at all on 64bits system. Did this change?

Also rather than put all files in one directory, I changed path in lazarus package.

[JD]

The last time I tested (09/2010), I succeeded to compile and use 10.5.8 (latest at this time). However it was not working at all on 64bits system. Did this change?

Also rather than put all files in one directory, I changed path in lazarus package.

I don't have a 64 bit system so I can't say if it works or not on 64 bit systems. You can always go over to the Indy forums & ask.

Cheers

JD

[marcov]

"not working at all" is horribly vague? Not compiling ? If so what, with what error?

Running? Designtime installing?

[thierrybo]

Sorry,

I just remember it did not build on Win 7 64 bits, but it was 7 months ago, I do not have the details any more.  .

Uhm, however I remember it work with Linix 64 bits. I just opened a lazarus test build I done at the same time and Indy builds. However I remember I had to tweak some files, as I want to keep files in their directory.

[jl]

Has anyone got idHTTP client to work under Linux for this version?   

[jl]

One could try to just remove the redundant versions of the various .inc files. Mostly notably idcompilerdefines.inc

With that change, I can compile it easily.

I tried this on the latest Indy10_4625 + fpc 2.4, copied *.pas, *.lrs and *.inc of the \System, \Core, and \Protocols subdirectories into a new indy folder.  For repeated .inc, i simply override them.

I end up with the following inc.

IdCompilerDefines.inc
IdCore90ASM90.inc
IddclCore90ASM90.inc
IddclProtocols90ASM90.inc
IdProtocols90ASM90.inc
IdSecurity90ASM90.inc
IdSystem90ASM90.inc
IdVers.inc

However, to make it easier to switch indy versions, I did not install the package.

I merely add ..\indy to compiler options - \indy resides in the same parent folder as my project folder.

So after this, I created a test HTTP Console client, tested on both Win32 and Ubuntu platform.  On Win32, the HTTP client worked but generated some heap trace:

<HTTP GET RESULTS>

Heap dump by heaptrc unit
2798 memory blocks allocated : 632164/645624
2795 memory blocks freed     : 632096/645544
3 unfreed memory blocks : 68
True heap size : 262144 (144 used in System startup)
True free heap : 264720
Should be : 261728
Call trace for block $0184E5C8 size 28
  $004667AD  TIDTHREADSAFE__CREATE,  line 223 of D:/Data/test/SMSD
tcher/lanprowler/Indy10_4625 test/indy/IdThreadSafe.pas
  $00466735  IDTHREAD_init,  line 638 of D:/Data/test/test/Indy10_4625 test/indy/IdThread.pas
  $0040A1A4
  $0040E271
  $00730065
  $0052005C
  $0078006F
  $006F0069
Call trace for block $01846AA0 size 12
  $00466735
  $0040A1A4
  $0040E271
Call trace for block $0184E4E8 size 28
  $004443EC
  $0040A1A4
  $0040E271
  $0077006F
  $00720065
  $00680053
  $006C0065
  $005C006C

On Ubuntu, it doesn't work at all:

Error: Connection Closed Gracefully.

Heap dump by heaptrc unit
568 memory blocks allocated : 46766/49648
565 memory blocks freed     : 46698/49568
3 unfreed memory blocks : 68
True heap size : 458752
True free heap : 458432
Should be : 458480
Call trace for block $B7765300 size 28
  $080F6D5D  TIDTHREADSAFE__CREATE,  line 223 of /home/jtest/Desktop/Data/Indy10_4625 test/indy/IdThreadSafe.pas
  $080F6B25  IDTHREAD_init,  line 638 of /home/jtest/Desktop/Data/Indy10_4625 test/indy/IdThread.pas
  $0805A6D4
  $081149DD
Call trace for block $B77446C0 size 12
  $080F6B25  IDTHREAD_init,  line 638 of /home/jtest/Desktop/Data/Indy10_4625 test/indy/IdThread.pas
  $0805A6D4
  $081149DD
Call trace for block $B7765220 size 28
  $080C376C  IDSTACK_init,  line 937 of /home/jtest/Desktop/Data/Indy10_4625 test/indy/IdStack.pas
  $0805A6D4
  $081149DD

My test console:

program project1;

{$mode objfpc}{$H+}

uses
  {$IFDEF UNIX}{$IFDEF UseCThreads}
  cthreads,
  {$ENDIF}{$ENDIF}
  Classes, SysUtils, CustApp, IdHTTP
    { you can add units after this };

type

  { TMyApplication }

  TMyApplication = class(TCustomApplication)
  protected
    procedure DoRun; override;
  public
    constructor Create(TheOwner: TComponent); override;
    destructor Destroy; override;
    procedure WriteHelp; virtual;
  end;

{ TMyApplication }

procedure TMyApplication.DoRun;
var
  ErrorMsg,Text: String;
    indy: TIdHTTP;
begin
  // quick check parameters
  ErrorMsg:=CheckOptions('h','help');
  if ErrorMsg<>'' then begin
    ShowException(Exception.Create(ErrorMsg));
    Terminate;
    Exit;
  end;

  // parse parameters
  if HasOption('h','help') then begin
    WriteHelp;
    Terminate;
    Exit;
  end;
  try
     try
     indy:= nil;
     indy:=TIdHTTP.Create(nil);
     indy.Name:='httpclient';
     indy.HandleRedirects:=true;
     Text := indy.Get('http://www.google.com');
     writeln(Text);

    except
          on E: Exception do
              writeln('Error: '+ E.Message);
    end;
  finally
   FreeAndNil(indy);
  end;


  // stop program loop
  Terminate;
end;

constructor TMyApplication.Create(TheOwner: TComponent);
begin
  inherited Create(TheOwner);
  StopOnException:=True;
end;

destructor TMyApplication.Destroy;
begin
  inherited Destroy;
end;

procedure TMyApplication.WriteHelp;
begin
  { add your help code here }
  writeln('Usage: ',ExeName,' -h');
end;

var
  Application: TMyApplication;

//{$R *.res}

begin
  Application:=TMyApplication.Create(nil);
  Application.Run;
  Application.Free;
end.

Any thoughts?  Thanks.