This was discussed in the past and so far, it seems possible for Unix
builds, although it’s going to be messy since the compile would generally
need access to all a large portion of the headers in the source tree, since
the “things needed to create your own op” aren’t necessarily all contained
in the include/mxnet directory.

On Tue, Mar 6, 2018 at 11:40 AM kellen sunderland <
kellen.sunderl...@gmail.com> wrote:

> Could we actually just define a mechanism so the libs could register their
> ops at runtime?  No linking required?
>
> On Tue, Mar 6, 2018, 8:36 PM Pedro Larroy <pedro.larroy.li...@gmail.com>
> wrote:
>
> > This is a good point. What additional blockers would there be for linking
> > against a user provided library with custom operators?
> >
> >
> >
> > On Tue, Mar 6, 2018 at 5:16 PM, Barber, Christopher <
> > christopher.bar...@analog.com> wrote:
> >
> > > To avoid this kind of problem, you really need to support features that
> > > allow MXNet to be extended without having to resort to forking. There
> is
> > > currently no way to add C++ custom operators without forking, and no
> way
> > to
> > > share such operators across projects. This creates a perverse incentive
> > to
> > > try to get changes that may not belong into the main product.
> > >
> > > On 3/5/18, 6:26 PM, "Marco de Abreu" <marco.g.ab...@googlemail.com>
> > > wrote:
> > >
> > >     Hello,
> > >
> > >     we recently had a few cases in which it has been attempted to add
> new
> > >     functionality to old branches because a customer of somebodys
> > $DAY_JOB
> > >     requested it and was unable to switch to the latest release or that
> > > certain
> > >     feature did not make it into the release. This lead to quite a lot
> of
> > >     discussions and there was no clear standing within the community.
> > >
> > >     Just to cite semantic versioning:
> > >
> > >        1. MAJOR version when you make incompatible API changes,
> > >        2. MINOR version when you add functionality in a
> > > backwards-compatible
> > >        manner, and
> > >        3. PATCH version when you make backwards-compatible bug fixes.
> > >
> > >
> > >     We as a community agreed on following this system and I think we
> > should
> > >     either stick to it or drop it entirely - exceptions to SemVer are
> > > usually
> > >     discouraged. While I see that adding functionality might be a minor
> > > thing,
> > >     I don't think that we should educate our users into expecting us to
> > >     backport new features. The development happening on the Apache
> MXNet
> > >     repository should not be influenced by something like this;
> > especially
> > >     considering that whoever supports that customer on their $DAY_JOB
> can
> > >     assist them at creating a fork and cherrypicking that feature. But
> I
> > > don't
> > >     see much reason why we're running against best pracitices. One
> > > important
> > >     thing to note here is that we're not maintaining CI on old branches
> > and
> > >     neither are we making patch releases - so what do these users do?
> > > Compile
> > >     off a stale development branch with unvalidated changes?
> > >
> > >     In my opinion this whole topic is just causing trouble and
> > > fragementation
> > >     on our end. If a features doesn't make it into the release (for
> > > whatever
> > >     reason), so be it. But I think we should discuss this topic and
> > > emphasize a
> > >     no-exceptions-rule to SemVer.
> > >
> > >     Best regards,
> > >     Marco
> > >
> > >
> > >
> >
>

Reply via email to