After merging, we discovered that the fix did not work for Windows. Florian and I worked on a way to deal with this and merged a second commit for this issue just now. Test should pass this time.

Thanks for the review Florian, I just merged.

I opened a pull request: https://github.com/aibasel/downward/pull/194

Apparently, using the same installer file can have different outcomes. I have three data points: (1) installing on my local machine, (2) installing on the grid, and (3) installing through the Github actions. In cases (1) and (3), the dynamic libraries are provided and everything works just fine. In case (2), however, I tried multiple times and they were never generated. So we can either try to figure out why the script behaves differently on our grid, or we can just implement a solution that also works without the dynamic libraries. As Florian, I'm in favor of the latter option.

I would also prefer the option where the find script can return a static or dynamic library (whatever is found on the system).

So whether or not dynamic libraries are installed seems to depend on the used installer. For example, the one we use for our Github actions (also version 22.1.1) does generate them and does not fail to find the CPLEX installation. The installers Florian and I had on our systems did not, so we obtained the error. Now this discrepancy raises the question, whether it is actually necessary to change something in the CMAKE build process, or whether we just need to be aware that if somebody encounters the problem in the future, we need to point them to the right installer. Any opinions? I personally think it would be preferrable to deal with the possibility that the dynamic libraries are missing. However, this requires changes in the code that we're not quite sure about whether we want them. I can still set up the pull request if we'd like to have it as a discussion basis, but I'll wait until I hear more opinions.

The standard CPLEX installation of version 22.1.1 does not provide dynamic libraries for linking. We previously assumed this would be the case and therefore only looked for dynamic libraries when automatically searching for CPLEX within the CMAKE build process (in the file FindCplex.cmake). Since this script fails to find CPLEX version 22.1.1 (and probably higher) even though it is installed, we should fix this.

Florian and I considered several options how we could address this issue. We suggest to just allow linking the static library instead if the dynamic one cannot be found. The only doubt we have about this solution is that Florian has some memories about doing so in the past but encountering a problem somewhere in the process. However, nobody else involved in the recent CMAKE refactoring could confirm this. So our current plan is to just try it out and see what happens. I will set up a pull request and we will see whether the Github actions pass.