[lxc-devel] [PATCH] Add LXC version information to version.h
Serge Hallyn
serge.hallyn at ubuntu.com
Mon Dec 2 17:59:13 UTC 2013
Quoting S.Çağlar Onur (caglar at 10ur.org):
> Hey Stéphane,
>
> On Mon, Dec 2, 2013 at 10:34 AM, Stéphane Graber <stgraber at ubuntu.com> wrote:
> > On Sun, Dec 01, 2013 at 11:14:17PM -0500, S.Çağlar Onur wrote:
> >> So that applications can get the LXC version number at compile time.
> >>
> >> This can be used to make applications/bindings that support compiling against
> >> multiple versions of LXC.
> >
> > So I guess that information would indeed be useful to some external
> > software/bindings.
> >
> > However I think we have to be careful there as my plan was to seriously
> > cut back in the number of public headers.
> >
> > The goal for 1.0 is for liblxc1 to be the only bits we export for out of
> > tree use, currently, that'd be lxccontainer.h and its rdepends so:
> > - lxccontainer.h
> > - lxclock.h
> > - attach_options.h
> >
> > Everything else would be available only for in-tree use.
>
> I see, that sounds like a good plan to me.
>
> > I guess we could have lxccontainer.h include version.h and then ship version.h.
> > Looking at it again, especially in view of your changes, I suspect we
> > could kill version.c and the lxc_version function and simply have
> > lxccontainer.c return LXC_VERSION. (That'd avoid both lxccontainer.h and
> > version.h exporting the same function with two different names).
> >
> > Actually I'm not completely sure we should even export lxclock, is there
> > any cases where we expect external users to want to mess with our locks?
<shudder>
> I think we don't need it. I would expect no one to use it externally.
-serge
More information about the lxc-devel
mailing list