Lazarus
Programming => Networking and Web Programming => Topic started by: JD on May 03, 2013, 11:40:57 am
-
Hi there everyone,
I just visited the Indy10 page on the Lazarus Wiki http://wiki.lazarus.freepascal.org/Indy_with_Lazarus (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/ (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
-
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.
-
-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
-
@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.
-
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.
-
(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.
-
..
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.
-
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.
-
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 :D
That's great since Lazarus/FPC is not being left behind by Delphi where Indy's evolution is concerned.
We must update that Wiki. :)
-
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:
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
-
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?
-
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).
-
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. :D
-
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...
-
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.
-
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.
It worked! Finally! Thanks for reminding me of the duplicate files, marcov. I used my tried and tested system i.e copy all necessary files (*.pas, *.lrs, *.inc) from the \Lib\Core, \Lib\Protocols, \Lib\System directories into a directory of my choice taking care not to duplicate already existing files. I then copied the modified IdRegisterCore.lrs and IdRegister.lrs (but not the modified IndyLaz.lpk) created by ChrisF into the directory I created. I then compiled the package twice, rebuilt the Lazarus IDE & I now have the Indy icons in 256 colors. :D Where there's a will, there's always a way.
Thanks marcov and ChrisF.
JD
-
Could anyone of you maybe eigh in on the issue I have encountered with Indy and OSX here:
http://forum.lazarus.freepascal.org/index.php/topic,28476.0.html (http://forum.lazarus.freepascal.org/index.php/topic,28476.0.html)
My setup works on Windows/Lazarus (1.4) but on OSX I have problems.
I have compiled and installed the indylaz with "-Ur"
When compiling a package that requires indylaz + has a unit from it in "uses" clause I get error
Can not find "idFTP used by "UmisvMyPackage", incompatible ppu = /Users/%myname%/MISV/LazarusComponents/indy_lazarus/Lib/lib/i386-darwin/idFTP.ppu, package indylaz -- You tried to use a unit of which the PPU file isn't found by the compiler. Check your configuration file for the unit paths
If I try compile a new fresh app where I e.g. drop TidFTP and ass idFTP unit to uses clause I get
Can not find "idFTP used by "UmisvMyApplication", Make sure all ppu files of a package are in its output directory = /Users/%myname%/MISV/LazarusComponents/indy_lazarus/Lib/lib/i386-darwin/idFTP.ppu, package indylaz -- You tried to use a unit of which the PPU file isn't found by the compiler. Check your configuration file for the unit paths
-
MISV:
I notice something I didn't notice before; "Incompatible PPU" means different version or architecture.
So somehow either the fpc compiler that is being executed is not what you think AND/OR the ppu's don't match it.
Earlier I thought it was some minor gotcha that forced recompile but then the message is "Interface CRC not matching, recompiling' or something similar.
-
Hi Marcow,
I appreciate all the help you try give me.
I have tried to delete all .ppu files in the indylaz Lib/lib/i386-darwin/ folder before compiling something that requires/uses the package - i.e. a dependent package (the error message about incompatible) or application (where the error is slightly different)
If I e.g. compile a free new application in Lazarus/OSX, it runs in OSX. But if I add idFTP component to it, it fails. (So I think that means FPC/Lazarus/Sources compiler are correct?)
However, maybe there are source files from elsewhere? It is correct I moved my Indy Lazarus/Windows installing to OSX when I started the work on porting, but since I have tried removing all the PPU files then I am not sure what there if left to try? Could there be some option in a apckage file that survived the move from LAzarus/Windows to Lazarus/OSX?
-
It may sound obvious (i.e. you've probably already verify it), but:
- have you looked at the messages output when compiling Indy before installing it? Especially the concerned unit i.e. IdFtp ? Is it compiled correctly ? Without any error or warning ?
- have you looked at the IdFtp.ppu file in the concerned Indy subdirectory ? Is it present and with the same date/time that the other ppu files ?
- do you have any other idFtp.ppu file somewhere else ? In your package ? Or in any path of your package ? Anywhere else ?
Have you installed any other package than Indy (and your package) ?
It's not clear to me if you've done this test: testing IdFtp, but without your own package. I mean, a fresh FPC/lazarus installation + the Indy package only ?
What version of Indy are you using ? A recent one, from http://indy.fulgan.com ?
Is any other component of Indy working properly ? An idHttp component, for instance, within a simple test project ?
And finally: do you remember what kind of files you have transferred EXACTLY from Windows to OSX for your package ?
I guess one of them could be a problem (not necessarily a .ppu file). Theoretically, the whole ...Lib/lib/i386-win32 (or x86_64-win64) subdirectory should have be omitted during the copy.
It's also possible that there are some differences from "standard" Windows package files and "standard" OSX ones - i.e. options added/removed or different by default (sorry, I can't tell for this part).
Edit:
I'm not sure bout what you mean with "I have tried to delete all .ppu files in the indylaz Lib/lib/i386-darwin/ folder before compiling something that requires/uses the package".
What is it just to check something (I mean the compilation can't succeed any longer, anyway) ?
To see if there is a different error message ?
Why not having just delete the IdFtp.ppu file to check the error message, in this case ?
Edit2:
Would it be possible that you have any other idftp.ppu file with a different case orthography (i.e. case sensitive problem - I don't know how your system is configured) ? Or that your package use a different case orthography for this unit ?
See: http://wiki.freepascal.org/User_Changes_2.4.0#Case_sensitivity_for_unit_names
...
New behaviour: All file systems are now treated as case-sensitive by default. The result is that the compiler will no longer always find units whose filename does not exactly match the unit name as it appears in the uses clause, even if the unit is located on a case-insensitive file system.
...
-
His Chris,
I can answer all of your questions / to-list items. I have tried them all :(
- I just use "idFTP as an example - it is whatever indy unit that is first placed in uses section. (So nothing from Indy compiles when used from anywhere.)
- I do not have any win32 folder in my OSX indy installation (only darwin)
- I have tried searching system for duplicate ppu file.
- I tried delete all ppu files to make sure they were all built / generated "fresh" again
- I am using an Indy version a couple of months old. (I only installed two other packages - lclextensions and virtualtreeview, none of which interact with Indy AFAIK)
- I have manually inspected the lpk file to see if anything appears wrong, but it does not appear so. (If anyone has a working Indy installation on OSX - do please upload it so I can compare?)
- I have tried checking case sensitivty. The .pas, .ppu file, compilter output error/log all use the same case.
-
So, if I'm correctly understanding you, you can compile correctly and install the Indy package (BTW, do you see its icons in your IDE ?), but you can't use it in any way.
In this case, could you check your indylaz.lpk file on OSX. Be sure to have this option:
<Type Value="RunAndDesignTime"/>
and especially not this one (at least one release of Indy has been done with an incorrect package file):
<Type Value="DesignTime"/>
-
Correct. Yes, I see icons, but I can't compile anything that uses it.
Everything looks correct to me, but I have attached the indylaz.lpk file here.
-
I can't see anything obvious in your package file, though there is one or two things a bit "strange".
Have you called it "indylaz.txt" instead of "indylaz.lpk" for a good reason (may be to upload it) ? Are you sure that it is this file which is used during your package installation, and not an "old" .lpk file still present ?
Apparently, the version is not the latest one, though it's still a recent one, indeed. What I find a bit strange is that I've never seen a recent Indy file build this way: may be because you've changed some options in your IDE for this package and re-saved it ?
What I find strange, for instance, is that you have only 13 files count in your package file: in the past it was 15, and since a while it's 14 AFAIK: IdDsnCoreResourceStrings.pas is missing. Why ? And I've got 14 both for my Indy 10.6.0 (build 5141) and 10.6.2 (build 5273), while yours is 10.6.1 (build 5238): just between the two of them.
So, where did you get your whole Indy package, exactly ?
Just to be sure, have you checked inside your IDE that your package has really been installed as "RunAndDesign" in its option: see attached capture for my own version.
Sorry, I can't see any other "good" reason explaining your problem. As a last chance, you can eventually make a try with the current version of Indy, i.e:
- uninstall your current Indy package, then remove all the Indy files currently present (sources, binary, config...) into your Indy package subdirectory,
- download the latest version from http://indy.fulgan.com/ (in ZIP directory - currently "Indy10_5274.zip");
- install it without any modification (you still need to compile it twice before rebuilding your IDE for it's final installation step).
BTW, have you also made a try with a simple test project by adding the absolute path of your Indy binaries into the search path of this project (-Fu compiler option):
Project - > Project Options - > Compiler options - > Paths - > Other unit files
-
I renamed it .txt, so it could be uploaded.
If anyone has a working lpk file on OSX - please upload it.
Yes, design and runtime :)
I originally changed file paths in my lpk because I wanted the paths to match. So I did not have those red cross over the filenames like in your screenshot. I believe this was necessary for the fulgan package to install, but I can not remember the specifics any longer.
I will try a reinstall, but my hopes are pretty low.
I have tried pointing "other files" to the ppu directory of Indy - does not work either :(
-
Same problem with a fresh untouched Indy installation. (I even deleted the old Indy directory and installed the new one in a complete new directory to make sure there were no leftover references)
Anyone here got Indy working on OSX / Lazarus 1.4?
-
I'm afraid there is an issue relative to the OSX environment: sorry...
Eventually, you can try to make a test directly with the Free Pascal compiler (i.e. not using Lazarus); with only a sample program and calling directly fpc.
A sample program: test.pas
program test;
uses
IdFTP;
var MyFTP: TIdFTP;
begin
MyFTP := TIdFTP.Create(nil);
MyFTP.UserName := 'anonymous';
MyFTP.Free;
WriteLn('Done');
end.
Compilation call for Windows, to adapt according to the proper configuration : comp.bat
dir C:\lazarus\components\indy\Lib\lib\i386-win32\IdFTP.*
C:\lazarus\fpc\2.6.4\bin\i386-win32\fpc -FuC:\lazarus\components\indy\Lib\lib\i386-win32\ test.pas
I'm not familiar with Mac OSX, but I guess it should be (more or less) equivalent to the following commands: to run into the OSX terminal
ls -l /path_for_Indy_binaries/IdFTP.*
/path_for_fpc_binaries/fpc -Fu/path_for_Indy_binaries/ test.pas
The aim of the dir/ls commands is to verify that the proper path and the proper filenames are correct for the Indy binary files (and eventually the corresponding permissions, too). It could be interesting to know if you really can "see" them, while fpc can't.
*** Edit ***
I just noticed that the Ftp unit for my Windows version of Indy are called IdFTP.* (as for in the zip file of Indy), while you are always referring to idFTP.* everywhere (especially in your error messages). Of course Windows doesn't care, but it could be the case for OSX: strange...
If it's really the case, you'll have to modify the test program and commands: IdFTP -> idFTP.
-
@MISV
My configuration:
- OSX 10.8.5(Mountain Lion)
- Indy 10.6.2.5274(the latest from http://indy.fulgan.com - downloaded on 25.05.2015)
- Lazarus 1.5 SVN version(r49172 - 26.05.2015)
*I can run a few tests on OSX 10.10(Yosemite) if is necessary, but I prefer not to, because I have a few project under development(Lazarus 1.2.6)
I have no problem compiling/installing Indy, then building/running applications.
1. Remove all previous indy installation
2. Download the following package(10.6.2.5274) from: http://www.2shared.com/file/eCHHk96r/Indy_1062.html
3. Extract the zip to $(LazarusDir)/Components/ directory
4. Open the package file, compile twice
5. Install Indy
6. Create a new project, add a few indy components(IdFTP for example) then go to Project/Options, add indy directory to Search Paths(http://i1269.photobucket.com/albums/jj581/balazsszekely/Indy%2010_1_zpsq0ydkwxb.png)
7. Build then Run (http://i1269.photobucket.com/albums/jj581/balazsszekely/Indy%2010_2_zpszknc3fwb.png)
-
6. Create a new project, add a few indy components(IdFTP for example) then go to Project/Options, add indy directory to Search Paths(http://i1269.photobucket.com/albums/jj581/balazsszekely/Indy%2010_1_zpsq0ydkwxb.png)
7. Build then Run (http://i1269.photobucket.com/albums/jj581/balazsszekely/Indy%2010_2_zpszknc3fwb.png)
Did you make the Indy About form yourself. It looks great!
Seeing your screenshots gives me assurance that Indy10 works in a Mac environment. I use it in Windows & Linux but the Mac was the final frontier for me. I can now say my Indy 10 apps work on all PC platforms.
JD
-
@JD
Did you make the Indy About form yourself. It looks great!
No! It's the original Indy About form since 2014. Install the latest indy, drop a component to your form, right click-->About Internet Direct(Indy).
-
@JD
Did you make the Indy About form yourself. It looks great!
No! It's the original Indy About form since 2014. Install the latest indy, drop a component to your form, right click-->About Internet Direct(Indy).
OK I see it now. I didn't know that. Thanks for the info.
By the way, have you been able to build Indy apps on the Mac? I don't have a Mac so I cannot test my apps.
JD
-
OK I see it now. I didn't know that. Thanks for the info.
You're welcome!
By the way, have you been able to build Indy apps on the Mac?
Yes! I created a client/server application(TIdTCPClient/TIdTCPServer). Actually it's not finished yet, but it's working fine on mac.
I don't have a Mac so I cannot test my apps.
If it's not a secret, feel free to post the source code. I can run a few tests for you.
*secret => I mean closed source :)
-
I don't have a Mac so I cannot test my apps.
If it's not a secret, feel free to post the source code. I can run a few tests for you.
*secret => I mean closed source :)
It actually is because I was commissioned to develop the application by an NGO.
A non-trivial example you can test for me can be found here http://www.delphigeist.com/2010/09/custom-client-server-application-with.html (http://www.delphigeist.com/2010/09/custom-client-server-application-with.html) I made a few twists & turns before I got it to work on Linux some years back. I'd like to know how it runs on a Mac.
Thanks,
JD
-
@JD
A non-trivial example you can test for me can be found here http://www.delphigeist.com/2010/09/custom-client-server-application-with.html I made a few twists & turns before I got it to work on Linux some years back. I'd like to know how it runs on a Mac.
It was written with an old version of Indy 10. Actually this is not a problem, I can easily convert it to Indy 10.6.2, but it contains a lot of delphi/windows specific stuff. I hope you don't aspect me to recode a large part of the project, just for the sake of the demo.
-
...
1. Remove all previous indy installation
2. Download the following package(10.6.2.5274) from: http://www.2shared.com/file/eCHHk96r/Indy_1062.html
3. Extract the zip to $(LazarusDir)/Components/ directory
4. Open the package file, compile twice
5. Install Indy
6. Create a new project, add a few indy components(IdFTP for example) then go to Project/Options, add indy directory to Search Paths(http://i1269.photobucket.com/albums/jj581/balazsszekely/Indy%2010_1_zpsq0ydkwxb.png)
7. Build then Run (http://i1269.photobucket.com/albums/jj581/balazsszekely/Indy%2010_2_zpszknc3fwb.png)
Just for my own information (as I don't have any access to a Mac neither)...
1/ You are adding the Indy binaries path to your project (step 7). Is it really necessary ? Is it a specific need for the OSX ? Is it also the case if you add manually (i.e. when not using a "visual" Indy component) the Indy package into the required package list ?
I mean, theoretically when using a "visual" component, indylaz is added automatically in the required package list, and the path to the Indy binaries are also added automatically when the compilation is done.
And for the other case, adding the Indy package into the required package list should be sufficient (this is the way to provide compatibility between various installations for a package; the exact location of the package binaries may be different from a user/computer to another).
Is all this mechanism not working properly for OSX ?
2/ I see you've chosen the "all in one directory" option for installing Indy. Is it just because you are used to do it (I know it was necessary in the past, unless modifying the lazarus package file) ? Or is it because the "subdirectory" option is not working when installing Indy on OSX ?
I mean, the Lazarus package file released currently with Indy is supposed to now work properly with subdirectories; at least, it's the case with Windows.
Is it not working with OSX ?
-
@JD
A non-trivial example you can test for me can be found here http://www.delphigeist.com/2010/09/custom-client-server-application-with.html I made a few twists & turns before I got it to work on Linux some years back. I'd like to know how it runs on a Mac.
It was written with an old version of Indy 10. Actually this is not a problem, I can easily convert it to Indy 10.6.2, but it contains a lot of delphi/windows specific stuff. I hope you don't aspect me to recode a large part of the project, just for the sake of the demo.
I'll recreate the cross platform (Win/Linux) version I made some years ago & I'll post it here in a few days time so that you can add any Mac specific code that is needed. What do you think?
-
It seems the combination of upgrading both to the latest Indy version + fixing my case in source seems to help to some degree. (I had some errors with units names.)
...
Now I have the compiler past the point where I had problems earlier. before I would *always* get problems when compiling my test application that required both indylaz and my own package (that also required and used indy .... typically in a unit found here I would encounter the problem --- but received a different error when compiling/installing the package)
...
Instead I am now getting errors inside the Indy units (when compiling indylaz) that it can't find the other Indy units, but it is a major step forward!to compile)
Update:
One example: IdHTTP ... it tries to use unit "IdHTTPHeaderInfo"... This gives an error... I think it is differences in: Unit name on disk, Unit name in file, unit name in use clause, but I have researched this to the end yet.
-
It seems the combination of upgrading both to the latest Indy version + fixing my case in source seems to help to some degree. (I had some errors with units names.)
@MISV I decided to look into the problems you are having. I uninstalled my old Indy I0 installation in Linux Mint. I downloaded the latest version for 26 May 2015 & I just selected indylaz.lpk, compiling it twice & installed it in the Lazarus 1.2.6 IDE. I then ran my usual tests after installation & it works fine. I did the same thing in Windows last week so I know it works.
Your problems may go away if you do a fresh installation of Indy
-
@ChrisF
I see you've chosen the "all in one directory" option for installing Indy. Is it just because you are used to do it (I know it was necessary in the past, unless modifying the lazarus package file) ? Or is it because the "subdirectory" option is not working when installing Indy on OSX ?
Partly because I'm use to it, but most importantly, those seven steps described in my previous post always works, on every platform.
@ChrisF
I mean, the Lazarus package file released currently with Indy is supposed to now work properly with subdirectories; at least, it's the case with Windows.
I will test it tomorrow under OSX with subdirectories and report back. According to @MISV it's not working properly.
@JD
I'll recreate the cross platform (Win/Linux) version I made some years ago & I'll post it here in a few days time so that you can add any Mac specific code that is needed. What do you think?
Ok. Usually if it works both under windows and linux, with little or no modification will work on mac too.
@MISV
It seems the combination of upgrading both to the latest Indy version + fixing my case in source seems to help to some degree. (I had some errors with units names.)
Did you try my "all in one directory" package?
-
@GetMem:
Yes it's interesting, because depending of your tests and experience with Indy on OSX, it could be useful to modify the wiki page concerning Indy (OSX section).
@GetMem and MISV:
If I've correctly understand what I've read, it's possible to indicate when created if the partition for the FS on OSX have to be case sensitive or not. May be your configurations for this point are not identical : i.e. case sensitive for MISV and not for GetMem (it's just an hypothesis).
-
@MISV Sorry if I sound Like a broken record but have you tried to follow GetMem's step-by-step instructions?
-
Hi,
My best guess right now is that OSX is case sensitive and that both me (in my own code) and Indy itself sometimes have mismatch between
- filename on disk
- actual unit name (i.e. "Unit xyz")
- how it is referenced in other units in "Uses"
Above problem also manifests itself in different error messages depending on if I am compiling an application using indylaz or my own package that uses indy.
I also think the error message is sometimes wrong. i.e. one part of Lazarus logs/shows one unit name, but it is actual another case version it can not find. I.e. it may be trying to find "XXX" but show it can not find "xxx". I think that was partly why I was spending time on wild goose chases where I could not see what was wrong.
I have found someone else having eperienced something very similar:
http://atozedsoftware.newsgroups.archived.at/indy.general/201005/1005316656.html (http://atozedsoftware.newsgroups.archived.at/indy.general/201005/1005316656.html)
It may also be that my earler version of the Indy library had some configuration errors (having originally copied it from Windows) - at least problems manifiested themselves different.
Somehow this may also be an error 40 (i.e. 40 centimeters from screen) but I spent days trying out many different variations.
I will return at quickest possible time frame when I can somehow organize my findings into something sensible / reproducable. I am working actively on this.
-
@ChrisF
I was able to Compile/Install the "subdirectory" version of Indy 10.6.2 under OSX. If I drop a component(TIdFTP for example) to Form1, indylaz is added to Required Packages, the project is building/running fine. However in my projects I use TIdSync a lot for updating visual components from inside threads. TIdSync is located in /Core subdirectory. If I add IdSync to the uses clauses, the project fails to build(see attachment). Actually this can be reproduced under windows and linux too. The same behaviour it's not present when the "all in one directory" version is used. That's why I prefer latter one. The necessary files can be copied in less then a minute to a single directory.
PS: If it helps, my OSX is NOT case sensitive.
-
@ChrisF
I was able to Compile/Install the "subdirectory" version of Indy 10.6.2 under OSX. If I drop a component(TIdFTP for example) to Form1, indylaz is added to Required Packages, the project is building/running fine. However in my projects I use TIdSync a lot for updating visual components from inside threads. TIdSync is located in /Core subdirectory. If I add IdSync to the uses clauses, the project fails to build(see attachment). Actually this can be reproduced under windows and linux too. The same behaviour it's not present when the "all in one directory" version is used. That's why I prefer latter one. The necessary files can be copied in less then a minute to a single directory.
PS: If it helps, my OSX is NOT case sensitive.
I use IdSync/IdNotify a lot also because my apps are multithreaded. I got round it by adding IdSync.pas to the IndyLaz package & recompiling. See screenshot. So the subdirectory version still works.
JD
-
After I add IdSync to IndyLaz package the same problem exists with IdTask. Who knows how many unit I need to add until I'm able to compile the project? For now I'm gonna stay with "all in one directory" version. I guess it's just a personal preference.
-
After I add IdSync to IndyLaz package the same problem exists with IdTask. Who knows how many unit I need to add until I'm able to compile the project? For now I'm gonna stay with "all in one directory" version. I guess it's just a personal preference.
I actually wrote the "all in one directory" instructions so I have nothing against it. Can you please test the attached sample project on your Mac system? I did it in Linux & it did not ask me to add IdTask even though IdTask is in the uses clause. All this is just so that we can have coherent installation instructions on the platforms Lazarus supports. :D
-
Your test project is working fine under OSX, but I'm still unable to build my project unless I add IdTask to Indylaz package.
-
Your test project is working fine under OSX, but I'm still unable to build my project unless I add IdTask to Indylaz package.
Now that is very interesting. Thanks for testing it. If you look at the uses clause of the test project, IdTask is there. Can you try adding ALL the Indy units in your project to the test project and then try to recompile it? I want to know if there is a missing dependency somewhere.
Thanks,
JD
-
You might check my version of Lazarus Indy package. You find it attached in this post.
-
@ChrisF
I was able to Compile/Install the "subdirectory" version of Indy 10.6.2 under OSX. If I drop a component(TIdFTP for example) to Form1, indylaz is added to Required Packages, the project is building/running fine. However in my projects I use TIdSync a lot for updating visual components from inside threads. TIdSync is located in /Core subdirectory. If I add IdSync to the uses clauses, the project fails to build(see attachment). Actually this can be reproduced under windows and linux too. The same behaviour it's not present when the "all in one directory" version is used. That's why I prefer latter one. The necessary files can be copied in less then a minute to a single directory.
PS: If it helps, my OSX is NOT case sensitive.
Thanks for the test.
So apparently, it's "generally" working but there are still a few issues concerning the "subdirectories method".
Concerning the TIdSync unit, after verifying it's not surprising: the TIdSync.ppu file is absent (though TIdSync.dcu is present for the Delphi version, indeed). As indicated by JD, we could modify the lazarus package file to add a dependency (i.e. forcing the compilation of this unit during the installation process).
I've just made a quick check between the Free Pascal and Delphi binaries, for comparison purposes. There are a few other missing files, but TIdSync seems to be the more important -missing- one (and I'm not sure all the other ones are really necessary for Free Pascal).
As for JD, I'm a bit puzzled concerning the IdTask unit. This one is compiled and present in the binary directory. There is probably "something else" concerning this problem, and it could be interesting to know which one.
A final word: you can of course use whatever method prefer to install Indy (my goal was not to force anybody to use any particular method) , but I think it would be easier for other people to just use the standard package released by default for Indy: so, fixing it ( especially the Lazarus package file) might help them (if we can identify all the issues).
@Cyrax:
Looking briefly at your package file, the main difference I can see is the "IncludeFiles" section. For what purposes ? Are there any other important changes ?
-
As for JD, I'm a bit puzzled concerning the IdTask unit. This one is compiled and present in the binary directory. There is probably "something else" concerning this problem, and it could be interesting to know which one.
That sort of surprised me too because I did not have an issue with it until GetMem said it caused problems in OSX. I would also like to know why that is the case.
-
...
@Cyrax:
Looking briefly at your package file, the main difference I can see is the "IncludeFiles" section. For what purposes ? Are there any other important changes ?
I don't remember exactly why I added it there. Probably it was to get around compilation problems.
I have attached a SVN patch against original version of indylaz.lpk in to this post so you and others can see what have changed.
-
@ChrisF, @JD
Sorry for the late response! Apparently I was wrong, after a clean install + deleting all the files from my project's binary folder, everything is working as it should. The only unit is missing from Indylaz package is IdSync.
So who's gonna make the patch? :) It seems that Remy Lebeau is the only one who is committing nowadays to https://svn.atozed.com:444/svn/Indy10.
@JD If you want to test the project on Mac, send me a pm or post it here.
-
Yes, AFAIK only Remy Lebeau can do it.
But we can request a modification on the Azoted forum, in order he applies it: http://forums2.atozed.com/
I've already done it several times in the past. The main problem is that Remy Lebeau is usually very busy, and it can take time before the patch being applied.
@MISV:
Have you solved your problems ? At least most of them... I'm asking it, in case "case-sensitive OSX" would require some other patches.
-
I believe I have found a bug (or at least something that could be improved) in OSX/Lazarus that is not in Windows/Lazarus
Create a new application. Drop TIdHTTP and TIdFTP on the form.
Add "IdURi" to the usage claus (notice the case spelling)
If I do that, I will get an error that Lazarus in unit "IdHTTP" can not find the referenced unit "IdURi"... even though the "use" reference in "IdHTTP" unit is the correct "IdURI".
So in essence Lazarus spits out an error that is very confusing and make you look the wrong place. The error (wrong case) was actually in my own application unit. I think that was a contributing factor to my problem.
...
I will return again as/if I find more similar problems. (I still have not gotten my own code working, but I am trying work my way through.)