Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

After uninstalling Delphi 10 Seattle, removing all directories containing 'Embarcadero', then installing Delphi 10.2 Tokyo, my projects using Indy no longer compile:

Could not compile used unit 'IdSSLOpenSSLHeaders'
Nothing changed in the projects' search path (these are only relative to the project)
Tools/Delphi Options/Library/Browsing path contains $(BDS)\source\Indy10\Protocol (and Core and System), and IdSSLOpenSSLHeaders.pas is in c:\Program Files (x86)\Embarcadero\Studio\19.0\source\Indy10\Protocols\
Adding IdSSLOpenSSLHeaders to the uses clause does not help (12 other Indy file names were added automatically because I used design time components)
There is a TIdSSLIOHandlerSocketOpenSSL component on the form
There is nothing relating to Indy in the Tools/Delphi Options/Library/Library Path
IdSSLOpenSSLHeaders.dcu etc. are in the c:\Program Files (x86)\Embarcadero\Studio\19.0\lib\win32\release\ folder
The editor shows red wigglies under IdSSLOpenSSL in the Uses clause, with hint 'Cannot resolve unit name'
There are no old id*.dcu files in unexpected places on the disk
I found two workarounds that I'm both not particularly happy with:
The Indy files are not part of the project; explicitly adding IdSSLOpenSSLHeaders.pas to the project makes it compile again, but I'm not happy about that: IdSSLOpenSSLHeaders.pas now compiles in that source directory, leaving a .dcu file there.

Besides, all the other Indy files are not part of the project.
Copying IdSSLOpenSSLHeaders.pas and IdCompilerDefines.inc to my projects' directory
Is there a better solution that I'm overlooking?
I am trying to create a small project to reproduce the issue, but so far this compiles???
Found it.
There were two projects involved, with some common files. Whichever one of the two I tried to build, I got the error.
The solution was to delete all .dcu files local to both projects.
Don't ask me why, but it seems there was some (order?)* dependency that building either one was unable to resolve.

After this, the order in which I build does not matter.
Note: I was thinking about deleting my question because this is such a weird and unreproducable issue (a test program I was gradually complicating kept compiled without errors).
Instead I decided to self-answer; who knows who this may help in the future.
* While trying, I even tried changing the order of the file names in the Uses statement, but that did not help.
                I don't really see the point of retaining this question. You haven't got to the bottom of it. The detail in the question isn't sufficient to answer the question. If I were you I'd get rid of the whole lot.
– David Heffernan
                Jul 19, 2017 at 14:12
                Any reason why you (apparently) manually delete old .dcu files?  Why not just perform a "Clean"?
– J...
                Jul 19, 2017 at 14:42
                @J... What's a "Clean"?? The idea to delete them was just another wild idea after having tried many others.
– Jan Doggen
                Jul 19, 2017 at 14:51
                @JanDoggen Right-click your project - there are options Compile, Build, Clean.  Compile compiles the .dcus, etc.  Build compiles and then builds the output module (exe, dll, etc).  Clean deletes all the .dcus and other generated files from any previous build.  It's not a wild idea - it's in fact a good idea to clean regularly, especially before deployment builds, after version control updates (and before commits!), etc, to make sure that your codebase is still coherent and intact and that it's not just building with bad .pas files and old, but working, .dcus.
– J...
                Jul 19, 2017 at 16:27
                @J... If I interpret this correctly, the difference between 'clean' and 'build' would be that the first also removes .dcu files that do not 'belong' to the projects(s)? The build would recompile all those belonging to the project anyway.
– Jan Doggen
                Jul 20, 2017 at 17:19
        
Thanks for contributing an answer to Stack Overflow!
Please be sure to answer the question. Provide details and share your research!
But avoid …
Asking for help, clarification, or responding to other answers.
Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.