Anyone know what the problem is ?
1. Download Indy from http://www.indyproject.org/Sockets/fpc/indy-10.2.0.3.zip
2. Open lazarus\indylaz.lpk via Open package... (*.lpk)
3. Go to Params\Paths (-Fu) and put line
..\fpc;..\lazarus
Again, what is the obsession with "installing components into the IDE" - why not simply instantiate the class you need in code and use it as normal.
I guess some chest thumping is OK, but assuming everyone knows how to do that, is not. ;)It's got nothing to do with chest thumping. ;-) Think about what happens when you drop a component on a a form. The Form Designer addes a field variable of a specific type. It probably adds a new unit in the uses clause. It adds the "creation" code inside the *.lfm file.
Sooo, how about a step-by-step in how to use packages without installing them if it such a lamentable thought to install them instead?This was discussed so many times before. Take a look at the following link. It shows a fully working code example, instantiating a FTP Client instance and retrieves a directory listing from the FTP server.
Again, what is the obsession with "installing components into the IDE" - why not simply instantiate the class you need in code and use it as normal. No IDE install issues to worry about at all. With Lazarus IDE, MSEide, Maximus all supporting path macros, setting up flexible source paths has never been so easy, so you don't even need Lazarus Packages any more.
On a side note: I'm using the latest Indy 10 directly from their code repository with FPC 3.0 under FreeBSD - granted I didn't install it into Lazarus IDE (as I never do with any components I use), so I don't know if there are install issues or not. But I can say that Indy (from SVN) works perfectly out of the box.
Indy SVN: https://svn.atozed.com:444/svn/Indy10/trunk (https://svn.atozed.com:444/svn/Indy10/trunk)
ps:
Indy 10.2.0.3 is rather old. I believe the latest version is now at v10.6.2.
@snorkelThere are still some unresolved issues with indy 10.6.2, regardless if you install in the IDE or not. For example add IdSync to the uses clauses and try to compile/build a project, it will fail. Why you need IdSync? To update the GUI from inside a thread. It's a very important unit for Client/Server applications. The only fix I find so far is to copy all units in a single directory. This way everything works as it should.
I just installed 10.6.2 into Lazarus 1.6 rc2 using the package and it worked fine
There are still some unresolved issues with indy 10.6.2, regardless if you install in the IDE or not. For example add IdSync to the uses clauses and try to compile/build a project, it will fail.
Please see the comments in the Mantis report: bugs.freepascal.org/view.php?id=29564Did you see Sven's comment?
So again, the problem is not with Indy, but with Lazarus IDE.I compiled and installed many lazarus package before and I never encountered this strange behaviour. By the way, if I add IdSync to indylaz.lpk everything works fine, so I find it hard to believe, this is a Lazarus IDE and Lazarus Packages issue. Even if it is a lazarus package issue, still need to be fixed, most of us works with lazarus not MSEide.
Did you see Sven's comment?Yes, and please see my reply too.
I compiled and installed many lazarus package before and I never encountered this strange behaviour. By the way, if I add IdSync to indylaz.lpk everything works fine, so I find it hard to believe, this is a Lazarus IDE and Lazarus Packages issue.I don't find it so hard to believe at all. :) Your example of adding IdSync to indylaz.lpk just proves that. The IdSync unit is located in the unit paths specified in the indylaz.lpk package, so why doesn't Lazarus find it in the first place. If you ever review the actual compiler parameters that Lazarus IDE produces (run lazarus from a console window to see this easily), it makes many mistakes. It often injects compiler parameters I did not specify, adds conflicting parameters etc. This all has a knock-on effect and is one explanation why sometimes projects don't compile via Lazarus IDE, but does from the command line or from MSEide, Maximus IDE etc.
Even if it is a lazarus package issue, still need to be fixed, most of us works with lazarus not MSEide.Yes indeed, but it doesn't help that the Mantis report is filed under the wrong project. Currently it is filed under the "mantis" project (where you report Mantis Bug Tracker bugs), when it should be filed under the "lazarus" project. So currently no Lazarus developer is going to see that report, or any notifications for it.
...
Free Pascal Compiler version 3.0.0 [2016/01/10] for i386
Copyright (c) 1993-2015 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling test.pas
Compiling C:\WORK\INTER\indy\Lib\System\IdStreamVCL.pas
Compiling C:\WORK\INTER\indy\Lib\System\IdGlobal.pas
Compiling C:\WORK\INTER\indy\Lib\System\IdException.pas
Compiling C:\WORK\INTER\indy\Lib\System\IdResourceStrings.pas
Writing Resource String Table file: IdResourceStrings.rsj
Compiling C:\WORK\INTER\indy\Lib\System\IdStream.pas
Compiling C:\WORK\INTER\indy\Lib\System\IdStreamVCL.pas
...
Just for demonstration purposes, add the IdStreamVCL unit at the top of the "uses" clause (to be sure it's compiled before the IdGlobal unit) in your test program.
I guess a workaround could be to force to compile IdGlobal before IdStreamVCL (by putting it in the first place of the package compilation).As I mentioned, that is what the indylaz.lpk package already does.
...
And as you can see from the IdStream unit, you are not supposed to use IdStreamVCL directly, instead you should use IdStream and TIdStreamHelper if needed.
...