Recent

Author Topic: Indy 10 installation instructions on Wiki needs clarification/reorganisation  (Read 34784 times)

JD

  • Hero Member
  • *****
  • Posts: 1758
Quote
@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
Windows (10, 7) - Lazarus 2.0RC3/FPC 3.2, NewPascal, Delphi

Indy 10.6 series; mORMot; Zeos 7.2.1; SQLite, Firebird, PostgreSQL & MariaDB; VirtualTreeView 5.5.3 R1

GetMem

  • Hero Member
  • *****
  • Posts: 3508
Quote
OK I see it now. I didn't know that. Thanks for the info.
You're welcome!

Quote
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.

Quote
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  :)

JD

  • Hero Member
  • *****
  • Posts: 1758
Quote
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 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
Windows (10, 7) - Lazarus 2.0RC3/FPC 3.2, NewPascal, Delphi

Indy 10.6 series; mORMot; Zeos 7.2.1; SQLite, Firebird, PostgreSQL & MariaDB; VirtualTreeView 5.5.3 R1

GetMem

  • Hero Member
  • *****
  • Posts: 3508
Quote
@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.

ChrisF

  • Hero Member
  • *****
  • Posts: 542
...
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

  • Hero Member
  • *****
  • Posts: 1758
Quote
@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?
Windows (10, 7) - Lazarus 2.0RC3/FPC 3.2, NewPascal, Delphi

Indy 10.6 series; mORMot; Zeos 7.2.1; SQLite, Firebird, PostgreSQL & MariaDB; VirtualTreeView 5.5.3 R1

MISV

  • Hero Member
  • *****
  • Posts: 633
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.
« Last Edit: May 26, 2015, 05:22:23 pm by MISV »

JD

  • Hero Member
  • *****
  • Posts: 1758
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
« Last Edit: May 26, 2015, 05:57:40 pm by JD »
Windows (10, 7) - Lazarus 2.0RC3/FPC 3.2, NewPascal, Delphi

Indy 10.6 series; mORMot; Zeos 7.2.1; SQLite, Firebird, PostgreSQL & MariaDB; VirtualTreeView 5.5.3 R1

GetMem

  • Hero Member
  • *****
  • Posts: 3508
Quote
@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.

Quote
@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.

Quote
@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.

Quote
@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?
« Last Edit: May 26, 2015, 06:38:37 pm by GetMem »

ChrisF

  • Hero Member
  • *****
  • Posts: 542
@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).
« Last Edit: May 26, 2015, 08:54:36 pm by ChrisF »

JD

  • Hero Member
  • *****
  • Posts: 1758
@MISV Sorry if I sound Like a broken record but have you tried to follow GetMem's step-by-step instructions?
Windows (10, 7) - Lazarus 2.0RC3/FPC 3.2, NewPascal, Delphi

Indy 10.6 series; mORMot; Zeos 7.2.1; SQLite, Firebird, PostgreSQL & MariaDB; VirtualTreeView 5.5.3 R1

MISV

  • Hero Member
  • *****
  • Posts: 633
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

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.

GetMem

  • Hero Member
  • *****
  • Posts: 3508
@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.

JD

  • Hero Member
  • *****
  • Posts: 1758
@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
« Last Edit: May 27, 2015, 10:36:26 am by JD »
Windows (10, 7) - Lazarus 2.0RC3/FPC 3.2, NewPascal, Delphi

Indy 10.6 series; mORMot; Zeos 7.2.1; SQLite, Firebird, PostgreSQL & MariaDB; VirtualTreeView 5.5.3 R1

GetMem

  • Hero Member
  • *****
  • Posts: 3508
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.