samskalicky commented on pull request #18904: URL: https://github.com/apache/incubator-mxnet/pull/18904#issuecomment-675119119
> 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? ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
