All of lore.kernel.org
 help / color / mirror / Atom feed
* any reason for "cmake_" prefix on cmake_runcmake_build()?
@ 2021-03-08 11:22 Robert P. J. Day
  2021-03-08 18:37 ` [OE-core] " Khem Raj
  0 siblings, 1 reply; 6+ messages in thread
From: Robert P. J. Day @ 2021-03-08 11:22 UTC (permalink / raw)
  To: OE Core mailing list


  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?

rday

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [OE-core] any reason for "cmake_" prefix on cmake_runcmake_build()?
  2021-03-08 11:22 any reason for "cmake_" prefix on cmake_runcmake_build()? Robert P. J. Day
@ 2021-03-08 18:37 ` Khem Raj
  2021-03-10 11:38   ` Robert P. J. Day
  0 siblings, 1 reply; 6+ messages in thread
From: Khem Raj @ 2021-03-08 18:37 UTC (permalink / raw)
  To: Robert P. J. Day, OE Core mailing list



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

> 
> rday
> 
> 
> 
> 
> 

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [OE-core] any reason for "cmake_" prefix on cmake_runcmake_build()?
  2021-03-08 18:37 ` [OE-core] " Khem Raj
@ 2021-03-10 11:38   ` Robert P. J. Day
  2021-03-10 16:35     ` Khem Raj
  2021-03-10 21:27     ` Richard Purdie
  0 siblings, 2 replies; 6+ messages in thread
From: Robert P. J. Day @ 2021-03-10 11:38 UTC (permalink / raw)
  To: Khem Raj; +Cc: OE Core mailing list

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.

rday

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [OE-core] any reason for "cmake_" prefix on cmake_runcmake_build()?
  2021-03-10 11:38   ` Robert P. J. Day
@ 2021-03-10 16:35     ` Khem Raj
  2021-03-10 21:27     ` Richard Purdie
  1 sibling, 0 replies; 6+ messages in thread
From: Khem Raj @ 2021-03-10 16:35 UTC (permalink / raw)
  To: Robert P. J. Day; +Cc: OE Core mailing list

[-- Attachment #1: Type: text/plain, Size: 1803 bytes --]

On Wed, Mar 10, 2021 at 3:38 AM Robert P. J. Day <rpjday@crashcourse.ca>
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.


This is more towards code styling issue and we have not really bothered to
define such namespaces they cause more confusion than the problem they
solve since such things should be checked by linters other wise they fall
apart

>
>
> rday
>

[-- Attachment #2: Type: text/html, Size: 2521 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [OE-core] any reason for "cmake_" prefix on cmake_runcmake_build()?
  2021-03-10 11:38   ` Robert P. J. Day
  2021-03-10 16:35     ` Khem Raj
@ 2021-03-10 21:27     ` Richard Purdie
  2021-03-11  9:15       ` Robert P. J. Day
  1 sibling, 1 reply; 6+ messages in thread
From: Richard Purdie @ 2021-03-10 21:27 UTC (permalink / raw)
  To: Robert P. J. Day, Khem Raj; +Cc: OE Core mailing list

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.

Cheers,

Richard


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [OE-core] any reason for "cmake_" prefix on cmake_runcmake_build()?
  2021-03-10 21:27     ` Richard Purdie
@ 2021-03-11  9:15       ` Robert P. J. Day
  0 siblings, 0 replies; 6+ messages in thread
From: Robert P. J. Day @ 2021-03-11  9:15 UTC (permalink / raw)
  To: Richard Purdie; +Cc: Khem Raj, OE Core mailing list

[-- Attachment #1: Type: text/plain, Size: 2169 bytes --]

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2021-03-11  9:16 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-08 11:22 any reason for "cmake_" prefix on cmake_runcmake_build()? Robert P. J. Day
2021-03-08 18:37 ` [OE-core] " Khem Raj
2021-03-10 11:38   ` Robert P. J. Day
2021-03-10 16:35     ` Khem Raj
2021-03-10 21:27     ` Richard Purdie
2021-03-11  9:15       ` Robert P. J. Day

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.