> So can I say that all source code need to build will be inside Apache MXNet? > We may only import some other Java packages that are necessary to build > instead of consume as submodule.
I'm not sure I follow. Are you saying that Apache MXNet is not allowed to have dependencies? I see plenty of dependencies being downloaded and compiled when building MXNet. If you're saying JavaCPP cannot be one of those, why is that? If there is a reason that we can't go through Maven Central, we could have https://github.com/bytedeco/javacpp added as a git submodule here. Would that be acceptable? > However, during MXNet 1.x, we are facing one key issue: we have to separate > native binary with Java package due to license issue. As far as I know, > JavaCPP require both of them build together, can we separate native binary > with JavaCPP when we do the publish work and make it usable for user provide > their own native binary (e.g grab from pip wheel)? This requirement typically > came from GPU use cases, we have different GPU distribution for different > Arch/OS (CU101/CU102/CU110). Sure, JavaCPP will load from the the system path if it can't find what it needs from the class path. From the perspective of the build system bundling in JAR files, we can control that with the `copyLibs` flag like this here: https://github.com/bytedeco/gradle-javacpp/blob/master/samples/zlib/build.gradle#L42 Setting it to `false` will prevent it from bundling any library it links with or needs to preload. > To make it fully usable, there will be some additional tasks for JavaCPP such > as type-mapping to form all Java object into JavaCPP pointer. Will we have > similar stuff for MXNet? Yes, we can map everything to Pointer, that's not a problem. I could start to put something in a fork, I imagine in a `java` subdirectory similar to https://github.com/apache/incubator-mxnet/tree/master/python? -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/apache/incubator-mxnet/issues/17783#issuecomment-701903485
