mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Skalicky <notificati...@github.com>
Subject Re: [apache/incubator-mxnet] [RFC] MXNet external operators (#18904)
Date Mon, 17 Aug 2020 21:14:29 GMT
> 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
Mime
  • Unnamed multipart/alternative (inline, 7-Bit, 0 bytes)
View raw message