what happens if an included layer contains a "conf/site.conf" file?

what happens if an included layer contains a "conf/site.conf" file?

[Robert P. J. Day]

  still trying to isolate some weirdness from this morning, but i'm
playing with a vendor's amazingly convoluted BSP which wraps a bunch
of thud-generation layers in some shell scripts.

  long story short: given some gcc-generated compiler errors, i added
a site.conf file under conf/ in the build directory, and included in
it a single CFLAGS-related no-error setting.

  suddenly, i began getting a slew of recipe parse errors from the
fetch step, complaining about failure to parse numerous SRC_URI
values, all of which started with a variable that represented the top
level URL for the source. suspecting that the variable in question was
somehow undefined, i set it explicitly in my new site.conf, which
solved *those* parse errors but displayed more based on a *different*
leading variable. so i fixed that and etc, etc, etc.

  i was baffled as to where these variables should have been set, and
how they must have been set all this time until recently, until i
tracked down an obscure layer that was being pulled in, which provided
a site.conf file that defined those variables.

  which inspires me to ask -- is there a priority to including the
file "site.conf" such that it will be pulled in from a layer unless
there's an overriding version of that file in the build directory?
i've never run across this before.

rday

Re: [OE-core] what happens if an included layer contains a "conf/site.conf" file?

[richard.purdie]

On Thu, 2022-05-26 at 10:51 -0400, Robert P. J. Day wrote:
>   still trying to isolate some weirdness from this morning, but i'm
> playing with a vendor's amazingly convoluted BSP which wraps a bunch
> of thud-generation layers in some shell scripts.
> 
>   long story short: given some gcc-generated compiler errors, i added
> a site.conf file under conf/ in the build directory, and included in
> it a single CFLAGS-related no-error setting.
> 
>   suddenly, i began getting a slew of recipe parse errors from the
> fetch step, complaining about failure to parse numerous SRC_URI
> values, all of which started with a variable that represented the top
> level URL for the source. suspecting that the variable in question was
> somehow undefined, i set it explicitly in my new site.conf, which
> solved *those* parse errors but displayed more based on a *different*
> leading variable. so i fixed that and etc, etc, etc.
> 
>   i was baffled as to where these variables should have been set, and
> how they must have been set all this time until recently, until i
> tracked down an obscure layer that was being pulled in, which provided
> a site.conf file that defined those variables.
> 
>   which inspires me to ask -- is there a priority to including the
> file "site.conf" such that it will be pulled in from a layer unless
> there's an overriding version of that file in the build directory?
> i've never run across this before.

It works just like any other conf file. The first one found in BBPATH
wins.

Layers should not have site.conf files in them.

Cheers,

Richard

Re: [OE-core] what happens if an included layer contains a "conf/site.conf" file?

[Robert P. J. Day]

On Thu, 26 May 2022, richard.purdie@linuxfoundation.org wrote:

> On Thu, 2022-05-26 at 10:51 -0400, Robert P. J. Day wrote:
> >   still trying to isolate some weirdness from this morning, but i'm
> > playing with a vendor's amazingly convoluted BSP which wraps a bunch
> > of thud-generation layers in some shell scripts.
> >
> >   long story short: given some gcc-generated compiler errors, i added
> > a site.conf file under conf/ in the build directory, and included in
> > it a single CFLAGS-related no-error setting.
> >
> >   suddenly, i began getting a slew of recipe parse errors from the
> > fetch step, complaining about failure to parse numerous SRC_URI
> > values, all of which started with a variable that represented the top
> > level URL for the source. suspecting that the variable in question was
> > somehow undefined, i set it explicitly in my new site.conf, which
> > solved *those* parse errors but displayed more based on a *different*
> > leading variable. so i fixed that and etc, etc, etc.
> >
> >   i was baffled as to where these variables should have been set, and
> > how they must have been set all this time until recently, until i
> > tracked down an obscure layer that was being pulled in, which provided
> > a site.conf file that defined those variables.
> >
> >   which inspires me to ask -- is there a priority to including the
> > file "site.conf" such that it will be pulled in from a layer unless
> > there's an overriding version of that file in the build directory?
> > i've never run across this before.
>
> It works just like any other conf file. The first one found in BBPATH
> wins.
>
> Layers should not have site.conf files in them.

  that's what i wanted to hear -- that i should not have had to debug
someone sneaking a site.conf into a single layer mixed in with 40
other layers. thanks.

rday