Indy 10 installation instructions on Wiki needs clarification/reorganisation

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

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. 

[balazsszekely]

Your test project is working fine under OSX, but I'm still unable to build my project unless I add IdTask to Indylaz package.

[JD]

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

[Cyrax]

You might check my version of Lazarus Indy package. You find it attached in this post.

[ChrisF]

@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 ?

[JD]

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]

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

[balazsszekely]

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

[ChrisF]

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.

[MISV]

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