Forum > Networking and Web Programming
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 :D
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:
--- Quote from: marcov on April 11, 2011, 01:25:22 pm ---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.
--- End quote ---
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:
--- Quote from: JD on April 11, 2011, 02:36:53 pm ---
--- Quote from: marcov on April 11, 2011, 01:25:22 pm ---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.
--- End quote ---
--- End quote ---
That should have been find the same .inc *first*.
--- Quote ---
--- Quote ---The multiple includefile situation is known (and considered intended behaviour), and considered a bug in Delphi that it allows it.
--- End quote ---
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.
--- End quote ---
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)
--- Quote ---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. %)
--- End quote ---
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.
--- Quote ---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.
--- End quote ---
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.
--- Quote from: marcov on April 11, 2011, 03:25:18 pm ---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)
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page