rmp-py.i: include the same headers for bazel/non-bazel

[hzeller]

In the bazel version, there were a bunch of header files missing.

[hzeller]

it is unclear to me why there is a difference between Bazel and non-bazel compilation, but I also don't know the details of Swig.

At least now the difference between these two Versions is minimized.

[gemini-code-assist]

Code Review

This pull request adds the "//src/dbSta" dependency to the "src/rmp" Bazel build and reorganizes includes and forward declarations in "src/rmp/src/rmp-py.i". A critical issue was identified where removing forward declarations from the SWIG section (outside the "%{ ... %}" block) will prevent SWIG from recognizing these types under "#ifdef BAZEL", potentially leading to incorrect type wrappers or runtime errors. It is recommended to restore these forward declarations.

[gemini-code-assist]

By removing the forward declarations of utl::Logger, odb::dbBlock, odb::dbInst, and sta::dbSta from the SWIG section (outside the %{ ... %} block), SWIG will no longer recognize these types when parsing the manual declaration of class Blif under #ifdef BAZEL.

Note that the %{ ... %} block is only visible to the C++ compiler and is completely ignored by SWIG. Therefore, moving or keeping these declarations only inside %{ ... %} does not help SWIG. Without these forward declarations in the SWIG section, SWIG may generate incorrect type wrappers (e.g., failing to map them to the correct Python class proxies or generating type mismatch warnings/errors at runtime).

We should restore these forward declarations in the SWIG section under #ifdef BAZEL.

#ifdef BAZEL
namespace utl {
class Logger;
}

namespace odb {
class dbBlock;
class dbInst;
}

namespace sta {
class dbSta;
}

namespace cut {
class Blif

[hzeller]

//src/rmp:_rmp_py.so compiles successfully.

[hzeller]

did the CI get stuck ?

[maliberty]

ci is done

[maliberty]

it is unclear to me why there is a difference between Bazel and non-bazel compilation, but I also don't know the details of Swig.

I went down the rabbit hole on this question. In short bazel is trying to make modules that can be loaded standalone into python3 as wheels and cmake is not. This is a bad idea as it means each lib has a mostly full copy of OR. It is a bigger project to fix this.

[hzeller]

ok, but having the necessary headers should not make a difference, right ? The size of the resulting bazel-bin/src/rmp/_rmp_py.so is the same in both cases.

[maliberty]

Agreed, just wondered myself