> Since mxnet 2.0 generally aims to simplify the build system, shouldn't we > take this case as incentive to simplify it further and remove the complexity > that is currently blocking you on this matter? Maybe @pengzhao-intel and his > team as well as @ptrendx and his team could help here. > The complexity of our build system and dependency.closure are creating > various issues on different topics, so finding a proper solution that goes > above "#if" and compile time.options would he helpful for the project. >
> What about cmake subprojects? As in use MXNet as a subproject of the external > library. > Following up on this after an offline discussion with @leezu, all of the code change in this PR so far is to enable dynamically loading libraries containing operator implementations with our existing library loading capabilities in MXNet (ie. `MXLoadLib` and `mx.library.load`). How users build the operator object files to link into a shared library is totally separate. Whether they put the operator code in the **src/operator** directory and build or if they improve the existing MXNet CMakeLists.txt to enable building as a subproject they get the same library thats loaded via the code in this PR. As was mentioned before, cleaning up the CMakeLists.txt can be done in parallel or after this PR is merged. How would guys feel about taking that approach? -- You are receiving this because your review was requested. Reply to this email directly or view it on GitHub: https://github.com/apache/incubator-mxnet/pull/18904#issuecomment-675119119
