On Wed, 10 Mar 2021, Richard Purdie wrote:

> On Wed, 2021-03-10 at 06:38 -0500, Robert P. J. Day wrote:
> > On Mon, 8 Mar 2021, Khem Raj wrote:
> >
> > >
> > >
> > > On 3/8/21 3:22 AM, Robert P. J. Day wrote:
> > > >
> > > >    collecting some examples of inheritance of class functions using
> > > > EXPORT_FUNCTIONS, and ran across this routine in cmake.bbclass:
> > > >
> > > >    ... snip ...
> > > >    cmake_runcmake_build() {
> > > >  bbnote ...
> > > >  eval ...
> > > >    }
> > > >
> > > >    cmake_do_compile()  {
> > > >          cmake_runcmake_build --target ${OECMAKE_TARGET_COMPILE}
> > > >    }
> > > >    ... snip ...
> > > >
> > > > what puzzles me is that the routine cmake_runcmake_build(), despite
> > > > having a "cmake_" prefix, is not being exported with EXPORT_FUNCTIONS,
> > > > so while that's a perfectly respectable function, it's not clear why
> > > > it would have a "cmake_" prefix. is there some value to that prefix,
> > > > or is it just arbitrary?
> > >
> > > it does not intend to provide a default function like do_compile do_install
> > > exporting it is not necessary
> >
> >   no, that part i understand ... the nitpicky observation was the use
> > of the "cmake_" prefix for a function which was not intended to be
> > exported for the purpose of inheritance. sure, it's perfectly legal,
> > but in a stylistic sense, it just leaves open the possibility of
> > misinterpretation by someone reading the code.
> >
> >   a simpler style rule might be, "reserve classname_ prefixes for only
> > those routines you plan on exporting." but i admit this is a quibble.
>
> No, please lets not do that. Having come kind of standard prefixing
> for variables/functions in classes does help give people direction
> to know where to find code from tracebacks or variable definitions
> and the like.
>
> The use of EXPORT_FUNCTIONS is a bit of a special case which
> requires the prefixing but I really don't want to see any
> recommendation we drop all prefixes otherwise.

  fair, i was probably getting overly pedantic there. moving on ...

rday