> I think this would be much cleaner if it was a separate directory because: > > * Version control is much easier. Just update mxnet or `rm -rf` it without > extra cruft > * This reflects reality much better. Somebody else builds mxnet for `pip` > without knowing about my stuff. MXNet ships a docker in which I can build my > thing for binary compatibility. > * MXNet should be usable as a submodule. > > So my ideal instructions look more like > > 1. compile MXNet normally from a clean checkout > 2. cd into your own project, configure with `-DMXNET=/path/to/mxnet` and > compile. Sample project provided and part of integration tests. > 3. `my_op.so` built by my build system > 4. dynamically load shared library into MXNet via `mx.library.load()`
Agreed, if only MXNet codebase was better organized. We have headers/includes scattered throughout the codebase. Not just in *include/mxnet**. For example `mxnet_op.h` in in **src/operator** and [`include/mshadow/base.h` includes `mkl_blas.h`](https://github.com/apache/incubator-mxnet/blob/2610c10701c2b8155dbf094aaecba37ebbf67d0f/3rdparty/mshadow/mshadow/base.h#L173) which isnt in the MXNet codebase. Duplicating and reproducing the MXNet cmake flow for building custom operators is not worth the hassle/maintenance. If others have ideas that they wanna give it a whirl, feel free to checkout this branch and try building `min_ex.cc` in the `lib_external_ops` directory. Happy to collaborate on this. -- 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-674967821
