Indy 10 installation instructions on Wiki needs clarification/reorganisation

[JD]

Hi there everyone,

I just visited the Indy10 page on the Lazarus Wiki http://wiki.lazarus.freepascal.org/Indy_with_Lazarus and the installation instructions can be a bit confusing.

In my opinion, the installation instructions should be divided into two sections:

a) Installation from the stable Lazarus version (Indy 10.2.XX)
    How to install
    How to install[2]
    How to install (confirmed) on Windows - Indy 10.2.03

b) Installation from SVN at http://indy.fulgan.com/ (Indy 10.5.XXXX)
    How to install [3] Windows, Indy 10.5.8.0

I wrote the instructions for installing the SVN version of Indy10 (it was added to the Wiki by someone else) and it works perfectly in Windows and Linux. I just refreshed my installation this morning as you can see from the attached screenshot. Therefore, the Wiki instructions for (b) above should say that the installation instructions work in Windows and Linux. I know because I've installed it on both of them.

This way, new users can decide what version they want to install and use.

Cheers,

JD

[ChrisF]

In fact, there are still a few issues concerning the Indy installation for FPC (for the current fulgan release, I mean). Some of them are concerning the Windows flavor only, while some others are more general:

-you shouldn't have to put all the files into one single directory. It's just because the indylaz.lpk script is not correctly defined to access to the concerned sub-directories. A minor change can fix it,

-you have to compile the package twice, mostly of the time. Because of an issue into the FPC compiler: see bug reports http://bugs.freepascal.org/view.php?id=19673 and http://bugs.freepascal.org/view.php?id=24121 . Well, in fact only one file is recompiled the second time,

-icons inside the IDE are outdated. They are corresponding to the old 16 colors ones, though the 256 colors version is available (furthermore a few ones are missing); because the .lrs files have not been updated. See attached capture for a sample with the 256 colors version.

I've planned to propose my fixes for the FPC installation; I guess I should do it.

[JD]

-you shouldn't have to put all the files into one single directory. It's just because the indylaz.lpk script is not correctly defined to access to the concerned sub-directories. A minor change can fix it,

It is true that the IndyLaz.lpk script needs work. I preferred to let the author do it since the changes will then be included in subsequent releases.

-you have to compile the package twice, mostly of the time. Because of an issue into the FPC compiler: see bug reports http://bugs.freepascal.org/view.php?id=19673 and http://bugs.freepascal.org/view.php?id=24121 . Well, in fact only one file is recompiled the second time,

I haven't noticed this. I only compiled once.

-icons inside the IDE are outdated. They are corresponding to the old 16 colors ones, though the 256 colors version is available (furthermore a few ones are missing); because the .lrs files have not been updated. See attached capture for a sample with the 256 colors version.

You're right about the outdated icons. I was hoping this would be fixed for future releases. The newly released Indy 10.6 (I'm yet to test it) and above all Indy 11.

I've planned to propose my fixes for the FPC installation; I guess I should do it.

Please feel free to update the Wiki if you can.

JD

[ChrisF]

@JD
------
Well, you've most probably not noticed that one .pas file has been compiled twice during your installation process.

If you put all the needed files into one single directory, it works without any problem.

But if you use sub-directories (with a modified package script to allow them), you step into a compilation error. Because the second time, the compiler can't find the correct path. I don't remember all of the details, but I'm sure about this issue.

The only solution is to manually ask for a second compilation for the package: this time, only the concerned file is recompiled (in fact, only the checksum inside the .PPU file is updated), and there is no path issue.

The other solution being of course to manually put all the needed files into one single directory, as you've probably done. This way, the second time the compiler doesn't have any problem to find the needed directory as there is only one. And so, it can be all done in "one" compilation step only during the installation process.


In fact, when I was referring to fixes, I intended to mean fixes within the fulgan distribution. I've posted today a proposal for such fixes into the Indy forum. Depending of the answer of the coder(s), I may update then the Lazarus wiki.

[JD]

In fact, when I was referring to fixes, I intended to mean fixes within the fulgan distribution. I've posted today a proposal for such fixes into the Indy forum. Depending of the answer of the coder(s), I may update then the Lazarus wiki.

Have no fears on this one. Remy Lebeau (the package maintainer) is a very helpful person. I've nothing but praise for him for his assistance and availability where using Indy is concerned.

[ChrisF]

(Continuation of another topic, concerning fixes for the indy installation)

If I've not proposed my patches for the Indy installation here before, it's because I intended to propose them for the "official" fulgan releases. But as I've postponed to make my proposal a couple of times in the past and so, as it's still not done, here are them; at least for test purposes. Hopefully, they'll be included into the future indy releases, and/or similar fixes will be provided.

Basically, the changes concerns the package script (in order to use the provided sub-directories during the installation process), and the resource files (in order to get the 256 colors icons inside the Lazarus IDE).

Once you've downloaded the indy fulgan version (currently, version Indy10_5004) and unzipped it, here are the steps for the installation (anyhow, most of them are common to any lazarus package installation):


Preliminary note: As you may have already noticed, only the \Lib subdirectory of Indy is needed for the installation. In fact only \Lib\Core, Lib\System\ and \Lib\Protocols, and not all the files; but that's another matter...


1/ Copy the "\Lib" subdirectory in its final place : for instance in an "indy" directory created inside the "components" subdirectory of Lazarus (i.e. $(LazarusDir)components\indy ).

2/ Replace the "indylaz.lpk" file present into the \Lib subdirectory with the one provided with this post (i.e. attached file "Indylaz (for Indy10_5004).zip"). This script has been prepared for the 5004 release, but anyhow the only difference for all of the releases is an indication of the release version inside the script. You can modify it by yourself, or leave it as this. In this later case, the display for the package inside Lazarus will be incorrect; that's all (there is no other difference).

3/ Replace the resources files present into the concerned subdirectories of "\Lib" with the ones provided here, as follows:
- "IdRegisterCore.lrs"    into      "\Lib\Core"
- "IdRegister.lrs"        into      "\Lib\Protocols"

4/ Start Lazarus and open the lazarus package (as in my previous sample, "$(LazarusDir)components\indy\indylaz.lpk").

5/ Compile it. Compile it one more time (yes, twice !).

6/ Mark it for installation.

7/ Finally, recompile the Lazarus IDE (optimized version being most preferable). You should now see the new indy icons at the end of the palette toolbar.


Final note: 2 compilations are needed because of an FPC compiler issue, and because subdirectories are used in the package script. The second compilation is done automatically during the recompilation of the Lazarus IDE internally, when only one directory is used with all the needed files (but you have to manually transfer them in this case).
If you look at the messages into the message box after the second compilation that I've indicated (look at all messages, included those hidden), you'll see that one file has been recompiled indeed:
...
Compiling indylaz.pas
Compiling .\System\IdStreamVCL.pas
...


In case of any problem, question, observation,... please feel free to post them in response.

[JD]

..
Compiling indylaz.pas
Compiling .\System\IdStreamVCL.pas
...

Hmmm, I do remember that IdStreamVCL.pas was a difficult problem. The compiler was saying something about not being able to find it. I had to add the directory to the package's Unit path before it worked.

[ChrisF]

Yep. It's because the problem doesn't occur during the package compilation step itself, but when finally building the Lazarus IDE instead (i.e. lazarus.exe).

Basically:

1/ Indy package compilation step : OK. In fact, "something" is wrong, but it 's not noticeable at this step

2/ Lazarus IDE final building: all the compiled units are checked. Those concerning the Indy installation of course, but also all the main ones concerning the IDE itself and all the other packages.

During this check, something is detected as being not updated (an incorrect CRC inside one of the PPU files of the Indy package). So, the process decides to recompile the "offending" file. But the Indy package script is no more present at this step (it concerns only the Indy package compilation, certainly not the IDE compilation), and so an error occurred, as the compiler can't now find the correct Indy subdirectory.

So, finally the main problem is that an incorrect PPU file is produced during the Indy package compilation; due to "recursive" call units, and to inline functions uses (this is well explained into the bug report links I've provided in one of my former posts).

If the PPU file was correctly produced, the final IDE building step wouldn't require such an "extra" compilation for one of the Indy files, and everything would be fine !


**EDIT ** : This is why a second compilation is needed here. It just updates the wrong PPU Indy file and so, the Lazarus IDE building can be achieved without any error.

[JD]

It worked just as you described. Great job. But you might want to look at those *.lrs files you posted because the IDE icons are still the old ugly 16 bit icons.

By the way, I stand corrected. Indy10.5004 is the new Indy10.6 series 

That's great since Lazarus/FPC is not being left behind by Delphi where Indy's evolution is concerned.

We must update that Wiki. 

[ChrisF]

Concerning the trouble with the icons, it's a bit strange. I've just made a new Indy re-installation with the current version Indy10.5004 (aka Indy 10.6, you are right), using the resource files I've just posted before and everything is correct for me (see attached screen capture).

Are you sure that you've replaced the 2 concerned files, before the compilation ? In the right sub-directories ? Have you really completed a new Lazarus recompilation, then ?

In order to check by yourself:

Code: [Select]

Old (16 colors) resource files : 10/08/2012
IdRegisterCore.lrs : 51 Kb
IdRegister.lrs : 230 Kb

New (256 colors) resource files : 23/03/2013
IdRegisterCore.lrs : 59 Kb
IdRegister.lrs : 314 Kb


[JD]

Yes I followed the instructions to the letter. I don't know why it is so. 

Can you repost the 3 files but from your actual Indy installation?

[ChrisF]

OK. Here are EXACTLY the concerned files I've taken from my own Indy directory, used within Lazarus. But, as you can see by yourself, they are exactly the same as the former ones.

It's possible that there is something wrong with your last indy installations/de-installations.

I suggest you to de-install completely your current indy version, and to re-install it then, with the modified files:

-de-install your current indy package inside Lazarus,
-recompile the Lazarus IDE (optimize version for speed purposes). The indy icons should now be absent,
-delete you current indy directory and subdirectories, formerly used within Lazarus,
-recreate it, and process with the indy installation described in my former post (don't forget to update first the 3 provided files, of course).

[JD]

No change at all. I've done it 3 times and the result is the same. Dunno. Maybe it has something to do with Windows versions because I'm using the unreliable Vista. 

[ChrisF]

Well, even Vista is not "smart" enough to recreate the old resource files, if you've deleted them or replace them with the new ones.

So, I can see only 2 possible explanations:

-the Indy package compilation is still done with the old resource files: because of wrong files, wrong places, wrong paths, wrong i-just-dont-know... Wrong installation path seems to me the more probable one in this case; especially if you've still got some other old Indy directories somewhere else on your disk. Have you tried to search for all the "IdRegister.lrs" files present on your disk, for instance ? Which date and which size for them ?

-there is a problem during your compilation, and so you are still using the old Lazarus.exe file (an UAC problem, for instance ?). You can check the date of this file to be sure about that. BTW, are you using several versions of Lazarus ? For win32 and win64, for instance ? Or for cross-compilations ? That could be also another possible reason.
Have you also really seen that all the Indy icons were absent after having de-installed your old Indy version ? This could also be an indication, if it wasn't the case.


For an additional check, you may have a look at a specific Indy icon. Because some them are missing or incorrectly named into the 16 colors version of the resource files. In this case, a by-default icon is used for the corresponding component. While there is really a Indy icon in the 256 colors version ones.

Look at the "Indy - Clients Core" tab, for instance, for the last component (i.e. "TIdTraceRoute"). With the 16 color version, this icon is missing; so, a 256 colors by-default icon is provided by Lazarus (see capture "Check-Palette16.png"). While this icon is really present with my 256 colors resource files (see capture "Check-Palette256.png").
Plus the fact that the other ones are 256 colors ones, of course...

[marcov]

Hmmm, I do remember that IdStreamVCL.pas was a difficult problem. The compiler was saying something about not being able to find it. I had to add the directory to the package's Unit path before it worked.

Afaik removing duplicate include files helps too.