| Age | Commit message (Collapse) | Author |
|---|
|
commandline option
I can't actually see how this was working, nothing connected the commandline option
to the data in TaskData(). Drop the remaining pieces of this option, it was a relic
from a decade ago and we want deterministic builds, not random tries until something
might work.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
cooker.reset() can be called before we've actually setup the datastore. Gracefully
handle this case instead of the current traceback+exit.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Currently the original prefile and postfile passed when starting bitbake
server are 'sticky'. With the new memory resident model this doesn't make
sense as the server the system is started with isn't special.
This patch changes the code so the prefile/postfile are used if specified
on the commandline and not used otherwise. This makes the behaviour much
more predictable and expected and as an added bonus simplifies the code.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The current passing of "tracking" backwards and forwards, client to server
is ugly and complex and error prone. Instead, set this during showEnvironment
commands triggering a reset there if/as required.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This changes the way bitbake server works quite radically. Now, the
server is always a process based server with the option of starting
an XMLRPC listener on a specific inferface/port.
Behind the scenes this is done with a "bitbake.sock" file alongside
the bitbake.lock file. If we can obtain the lock, we know we need
to start a server. The server always listens on the socket and UIs
can then connect to this. UIs connect by sending a set of three file
descriptors over the domain socket, one for sending commands, one for
receiving command results and the other for receiving events.
These changes meant we can throw away all the horrid server abstraction
code, the plugable transport option to bitbake and the code becomes
much more readable and debuggable. It also likely removes a ton of
ways you could hang the UI/cooker in weird ways due to all the race
conditions that existed with previous processes.
Changes:
* The foreground option for bitbake-server was dropped. Just tail
the log if you really want this, the codepaths were complicated enough
without adding one for this.
* BBSERVER="autodetect" was dropped. The server will autostart and
autoconnect in process mode. You have to specify an xmlrpc server
address since that can't be autodetected. I can't see a use case
for autodetect now.
* The transport/servetype option to bitbake was dropped.
* A BB_SERVER_TIMEOUT variable is added which allows the server
to stay resident for a period of time after the last client
disconnects before unloading. This is used if the -T/--idle-timeout
option is not passed to bitbake.
This change is invasive and may well introduce new issues however I
believe the codebase is in a much better position for further
development and debugging.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Finding the top level build directory is currently hard and relies on
having a complete cooker being setup. Add a helper function which
does the same thing without all the extra overhead. This is needed
to be able to locate the bitbake lockfile and hence the socket
for connecting clients in the new server model.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Fix one incorrect indentation and several lines with trailing spaces.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
There are some cases where the metadata needs to be aware a multiconfig build
is happening and have access to the multiconfig data stores to merge data into
the common build. This adds such an event allowing access to these datastores.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Currently, someone trying a master branch of any given layer may
or may not find it works with the version of OE-Core that they
have picked.
This patchset introduces LAYERSERIES_CORENAMES and
LAYERSERIES_COMPAT_<layername> with the intention of allowing layers
to indicate which versions of the core project they're compatible with.
In general the master branch will use the next release codename as
the value of LAYERSERIES_CORENAMES, meaning that the waterfall model
of layer releases is supported with layers updating their
LAYERSERIES_COMPAT_ values as they branch for release.
Both variables support multiple strings and a given layer is accepted
if there is overlap of any one value. This means a layer can be compatible
with multiple core versions.
Setting LAYERSERIES_COMPAT_ will be required by the Yocto Project
Compatible v2 standard but the system will not error if its not set at this
point.
This should make it clear when a given layer is unmaintained and untested
with new releaes of OE-Core, a common user pain point.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
In OpenEmbedded's buildhistory class we want access to the bitbake
command line that launched the build, and up to now we were simply using
sys.argv from within the event handler to get that. Unfortunately that
doesn't work in memory resident mode, since the event handler is
naturally executing within the server and thus will give you the command
that launched the bitbake server which is much less interesting. Add a
dynamic variable BB_CMDLINE to provide access to this, set from sys.argv
within the UI process in updateToServer().
(Note that BB_CMDLINE isn't currently passed through to the worker, so
this is only really readable from event handlers plus any explicit
getVariable calls - in theory an observe-only UI could read it for
example.)
Part of the fix for [YOCTO #11634].
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
CookerConfiguration sets the "tracking" option to True when -e is
specified in order to have history tracking enabled in the datastore
so that we can show variable history (which isn't enabled by default for
performance reasons), however in memory resident mode this wasn't doing
anything because it was happening on the UI side only. We do have a
mechanism for updating the cooker configuration in the server, but the
tracking option wasn't being included in the list of options we updated,
so we just need to add this option to fix the issue.
Fixes [YOCTO #10730].
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
BBFILES_DYNAMIC can be used to activate content only when some other
layers are present. The other layers are identified by the collections
that they define.
The main use case is to avoid .bbappends without the corresponding .bb
file in layers that want to modify other layers via .bbappends without
introducing a hard dependency on those other layers. .bb files could
also be handled via BBFILES_DYNAMIC.
Entries in BBFILES_DYNAMIC must have the form <collection
name>:<filename pattern>. Example usage:
BBFILES_DYNAMIC += " \
clang-layer:${LAYERDIR}/bbappends/meta-clang/*/*/*.bbappend \
core:${LAYERDIR}/bbappends/openembedded-core/meta/*/*/*.bbappend \
"
Parsing is aborted when invalid entries are found with an error
message like this:
ERROR: BBFILES_DYNAMIC entries must be of the form <collection name>:<filename pattern>, not:
/work/my-layer/bbappends/meta-security-isafw/*/*/*.bbappend
/work/my-layer/bbappends/openembedded-core/meta/*/*/*.bbappend
Based on a patch by Richard Purdie.
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
For example:
$ bitbake core-image-minimal --runall unpack
...
NOTE: Tasks Summary: Attempted 326 tasks of which 88 didn't need to be rerun and all succeeded.
$ bitbake core-image-minimal --runall patch
NOTE: Tasks Summary: Attempted 453 tasks of which 332 didn't need to be rerun and all succeeded.
This can replace fetchall as well:
$ bitbake core-image-minimal --runall fetch
NOTE: Tasks Summary: Attempted 135 tasks of which 119 didn't need to be rerun and all succeeded.
Signed-off-by: Matthew McClintock <msm-oss@mcclintock.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
When we're running with bitbake -b, BB_TASKDEPDATA is incorrect and limited.
We really need a way to know this from the metadata and this new variable
provides this in worker context. This means existing code can stop having
to guess.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
People are struggling with multiconfig as the point the conf file
is injected into the data store is not what people expect. We can't
really use a post config since that is too late and we can't really
use a pre config file since that is too early. In OE terms, we need
something right around the local.conf point so it behaves in a similar
way.
A way to handle this is to set the new variable BB_CURRENT_MC to be the
currently selected multiconfig, then the metadata itself can choose
when to inject the approriate configuration.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
In memory resident mode we don't really want to actually shut down since
it's only the client going away.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
getVarFlag() now defaults to expanding by default, thus remove the
True option from getVarFlag() calls with a regex search and
replace.
Search made with the following regex:
getVarFlag ?\(( ?[^,()]*, ?[^,()]*), True\)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
getVar() now defaults to expanding by default, thus remove the True
option from getVar() calls with a regex search and replace.
Search made with the following regex: getVar ?\(( ?[^,()]*), True\)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The event handling 'Exception' was catching and triggering a backtrace. This
trace was obscuring any errors from an event handler that had raised the
BBHandledException, which should indicate do not print additional information.
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
[YOCTO #10188]
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
[YOCTO #10188]
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
[YOCTO #10186]
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This patch adds the notion of supporting multiple configurations within
a single build. To enable it, set a line in local.conf like:
BBMULTICONFIG = "configA configB configC"
This would tell bitbake that before it parses the base configuration,
it should load conf/configA.conf and so on for each different
configuration. These would contain lines like:
MACHINE = "A"
or other variables which can be set which can be built in the same
build directory (or change TMPDIR not to conflict).
One downside I've already discovered is that if we want to inherit this
file right at the start of parsing, the only place you can put the
configurations is in "cwd", since BBPATH isn't constructed until the
layers are parsed and therefore using it as a preconf file isn't
possible unless its located there.
Execution of these targets takes the form "bitbake
multiconfig:configA:core-image-minimal core-image-sato" so similar to
our virtclass approach for native/nativesdk/multilib using BBCLASSEXTEND.
Implementation wise, the implication is that instead of tasks being
uniquely referenced with "recipename/fn:task" it now needs to be
"configuration:recipename:task".
We already started using "virtual" filenames for recipes when we
implemented BBCLASSEXTEND and this patch adds a new prefix to
these, "multiconfig:<configname>:" and hence avoid changes to a large
part of the codebase thanks to this. databuilder has an internal array
of data stores and uses the right one depending on the supplied virtual
filename.
That trick allows us to use the existing parsing code including the
multithreading mostly unchanged as well as most of the cache code.
For recipecache, we end up with a dict of these accessed by
multiconfig (mc). taskdata and runqueue can only cope with one recipecache
so for taskdata, we pass in each recipecache and have it compute the result
and end up with an array of taskdatas. We can only have one runqueue so there
extensive changes there.
This initial implementation has some drawbacks:
a) There are no inter-multi-configuration dependencies as yet
b) There are no sstate optimisations. This means if the build uses the
same object twice in say two different TMPDIRs, it will either load from
an existing sstate cache at the start or build it twice. We can then in
due course look at ways in which it would only build it once and then
reuse it. This will likely need significant changes to the way sstate
currently works to make that possible.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The current codepaths are rather confusing. Stop passing these
as parameters and use the ones from when the object is created.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Makes it easier for user to identify problems, e.g. typos, in BBLAYERS.
[YOCTO #9507]
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This variable is a regex-escaped version of LAYERDIR, for safer use in
BBFILE_PATTERN, so as to avoid issues with regex special characters in the
layer path.
[YOCTO #8402]
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The string formatting wasn't correct and we should exit if we hit
errors here similar to the other exception handlers.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
It's very possible that we added layer as:
BBLAYERS += "/path/to/meta/"
then there would be warning:
WARNING: No bb files matched BBFILE_PATTERN_core '^/path/to/meta//'
This patch can fix the problem.
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
If local.conf contains an invalid line, e.g.:
APPEND += " igor"
(note the leading space) then nasty tracebacks are shown which confuse the
user. Change so the parse error is simply shown without a traceback, improving
the user experience.
[YOCTO #9332]
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Its turning out that we really need a way to have bitbake just run
the setscene tasks but not any real tasks, particularly for SDK
operations.
Add an option for this since its pretty straight forward. This allows
various nasty workarounds in OE-Core to be removed.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
correctly
Currently bitbake tracebacks can have places where the line numbers are
inaccurate and filenames may be missing. These changes start to try and
correct this.
The only way I could find to correct line numbers was to compile as a
python ast, tweak the line numbers then compile to bytecode. I'm open
to better ways of doing this if anyone knows of any.
This does mean passing a few more parameters into functions, and putting
more data into the data store about functions (i.e. their filenames
and line numbers) but the improvement in debugging is more than worthwhile).
Before:
----------------
ERROR: Execution of event handler 'run_buildstats' failed
Traceback (most recent call last):
File "run_buildstats(e)", line 43, in run_buildstats(e=<bb.build.TaskStarted object at 0x7f7b7c57a590>)
NameError: global name 'notexist' is not defined
ERROR: Build of do_patch failed
ERROR: Traceback (most recent call last):
File "/media/build1/poky/bitbake/lib/bb/build.py", line 560, in exec_task
return _exec_task(fn, task, d, quieterr)
File "/media/build1/poky/bitbake/lib/bb/build.py", line 497, in _exec_task
event.fire(TaskStarted(task, logfn, flags, localdata), localdata)
File "/media/build1/poky/bitbake/lib/bb/event.py", line 170, in fire
fire_class_handlers(event, d)
File "/media/build1/poky/bitbake/lib/bb/event.py", line 109, in fire_class_handlers
execute_handler(name, handler, event, d)
File "/media/build1/poky/bitbake/lib/bb/event.py", line 81, in execute_handler
ret = handler(event)
File "run_buildstats(e)", line 43, in run_buildstats
NameError: global name 'notexist' is not defined
----------------
After:
----------------
ERROR: Execution of event handler 'run_buildstats' failed
Traceback (most recent call last):
File "/media/build1/poky/meta/classes/buildstats.bbclass", line 143, in run_buildstats(e=<bb.build.TaskStarted object at 0x7efe89284e10>):
if isinstance(e, bb.build.TaskStarted):
> trigger = notexist
pn = d.getVar("PN", True)
NameError: global name 'notexist' is not defined
ERROR: Build of do_package failed
ERROR: Traceback (most recent call last):
File "/media/build1/poky/bitbake/lib/bb/build.py", line 560, in exec_task
return _exec_task(fn, task, d, quieterr)
File "/media/build1/poky/bitbake/lib/bb/build.py", line 497, in _exec_task
event.fire(TaskStarted(task, logfn, flags, localdata), localdata)
File "/media/build1/poky/bitbake/lib/bb/event.py", line 170, in fire
fire_class_handlers(event, d)
File "/media/build1/poky/bitbake/lib/bb/event.py", line 109, in fire_class_handlers
execute_handler(name, handler, event, d)
File "/media/build1/poky/bitbake/lib/bb/event.py", line 81, in execute_handler
ret = handler(event)
File "/media/build1/poky/meta/classes/buildstats.bbclass", line 143, in run_buildstats
trigger = notexist
NameError: global name 'notexist' is not defined
----------------
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Additional config files passed to bitbake server with --read and
--postread options are rewritten by client bitbake even if
it doesn't use those options.
This is a show stopper for toaster as toaster command line
builds are based on the assumption that server is aware of
toster configs, provided by --postread option.
This behaviour is fixed by preserving values of --read and
--postread options when bitbake server starts and restoring
them if client bitbake doesn't explicitly specify them.
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
BBPKGS is a confusing name from before we tried to straighten out our
terminology. Its also a mostly unknown variable that isn't in wide use.
I've been asked about it recently and before people start relying more
heavily on it, I'd like to rename it BBTARGETS which better describes
what it does. Its not currently in the manuals, I'd prefer to document
it under the better name. I've not provided any migration path for the
variable since I believe its unused currently.
It allows the targets to built to be specified from a conf file in
addition to those on the commandline.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Show the user only the portion of the traceback which was from the metadata,
nothing from bitbake's internal calls.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The prefile/postfile options weren't working in memory resident mode
because they weren't being passed through to the server, so ensure that
they do get passed through and that the server is reset when the values
come through.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Tracebacks are of extremely limited usefulness in this context. The exceptions
carry the necessary context already, and the user doesn't care about the calls
in bitbake internals that led to an expansion or parse failure.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Rather than just use d.getVar(X), use the more explict d.getVar(X, False)
since at some point in the future, having the default of expansion would
be nice. This is the first step towards that.
This patch was mostly made using the command:
sed -e 's:\(getVar([^,()]*\)\s*):\1, False):g' -i `grep -ril getVar *`
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Implemented processing of ~ in bblayer's paths if HOME
environment variable is approved.
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Moved most of functionality of bin/bitbake to lib/bb/main.py
to be able to call bitbake from python code.
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
If the environment changes, we need memory resident bitbake to adapt to those
changes. This adds in functionality to handle this alongside the configuration
option handling code. This means that the common usage:
MACHINE=X bitbake Y
now works with the memory resident server.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This patch adds a "-w/--write-log" option to bitbake
that writes an event log file for the current build.
The name of the file is passed as a parameter to the "-w"
argument. If the parameter is the empty string '', the file
name is generated in the form bitbake_eventlog_DATE.json,
where DATE is the current date and time, with second precision.
The "-w" option can also be supplied as the BBEVENTLOG
environment variable.
We add a script, toater-eventreplay, that reads an event
log file and loads the data into a Toaster database, creating
a build entry.
We modify the toasterui to fix minor issues with reading
events from an event log file.
Performance impact is undetectable under no-task executed builds.
Signed-off-by: Alexandru DAMIAN <alexandru.damian@intel.com>
|
|
When using options like -k, -f, -v and so on with the memory resident
server, they'd currently only be set on the initial values passed to
the original command. This ensures they now match those specified
on the commandline for the options where this makes sense.
To make this work, a command to update the options on the server side
is required so this is added.
[YOCTO #5292]
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
If we see errors during parsing, firstly its bad to show a traceback
for an expansion error so lets suppress this.
Secondly, raise a BBHandledException instead of a SystemExit to show
we've informed the user about the condition (printing a traceback in the
default unknown case).
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
There is no easy way to make this change. We really need parameters for the -S
(dump signatures) handling code. Such a parameter can then be used within the
codebase to handle the signatures in different ways.
For now, "none" is the recommended default and "printdiff" will execute the
new (and more expensive) comparison algorithms.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The idea is to build on the --status-only option for bitbake and
expose a mechanism where the oe init scripts can easily switch between
memres server and the non-memres server.
In the case of the standard oe init script the following
can shut down the server:
if [ -z "$BBSERVER" ] && [ -f bitbake.lock ] ; then
grep ":" bitbake.lock > /dev/null && BBSERVER=`cat bitbake.lock` bitbake --status-only
if [ $? = 0 ] ; then
echo "Shutting down bitbake memory resident server with bitbake -m"
BBSERVER=`cat bitbake.lock` bitbake -m
fi
fi
A similar function can be used to automatically detect if the server
is already running for the oe memres init script. This new
functionality allows for the memres init script to be started in a new
shell and connect up to an alaready running server without seeing the
error of trying to start the server multiple times.
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Implementing feature set selection that allows a client
to enable specific features in the server at connection time.
Only enabling of features is supported, as there is
no way to safely remove data loaded into the cooker.
Once enabled, a feature will remain enabled for the
life of the cooker.
Client-server connection now supports specifying the feature
set required by the client. This is implemented in the Process
server using a managed proxy list, so the server cooker
will now load dynamically needed features based on what client
connects to it.
In the XMLRPC server the feature set is requested by
using a parameter for registerUIHandler function.
This allows observer-only clients to also specify features
for the server.
The server code configuration now is completly separated
from the client code. All hardcoding of client knowledge is
removed from the server.
The extra_caches is removed as the client can now specify
the caches it needs using the feature. The UI modules
now need to specify the desired featureSet. HOB is modified
to conform to the featureSet specification.
The only feature available is CookerFeatures.HOB_EXTRA_CACHES
which forces loading the bb.cache_extra:HobRecipeInfo class.
Signed-off-by: Alexandru DAMIAN <alexandru.damian@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
It should be possible to run a build anywhere on the filesystem and have
bitbake find the correct build directory if its set somehow. The BBPATH
variable makes perfect sense for this usage. Therefore use any available
value of BBPATH to search for conf/bblayers.conf before walking the parent
directory structure.
This restores the option of being able to run bitbake from anywhere if
the user has set things up to operate in that environment.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
By definition, bblayers.conf is at the top of the build tree. We'd like
to support running bitbake anywhere within that build tree but TOPDIR
gets set to wherever cwd is. Change the code to reset TOPDIR
to the top of the build directory.
This shouldn't break anything but does make the system more usable.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
If BBPATH isn't set and bblayers.conf isn't found, improve the message
shown to the user to help their understanding of what the problem might
be.
[YOCTO #3271]
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A
|
Richard Purdie
Paul Eggleton
Patrick Ohly
Matthew McClintock
Joshua Lock
Mark Hatle
Markus Lehtonen
Christopher Larson
Robert Yang
Ed Bartosh
Alexandru DAMIAN
Jason Wessel