TipsAndTricks/CliBuildsInToasterBuilddir - Revision history

David Reyna: /* How to Take Over a Toaster Build Dir from the Command Line */

2018-05-23T02:56:49Z

How to Take Over a Toaster Build Dir from the Command Line

← Older revision		Revision as of 02:56, 23 May 2018
Line 19:		Line 19:
	<code> cd build-toaster-1;. <path>/poky/oe-init-build-env </code>		<code> cd build-toaster-1;. <path>/poky/oe-init-build-env </code>
	*You need to run bitbake like		*You need to run bitbake like
	<code> bitbake -R conf/toaster.conf -r conf/toaster-bblayers.conf<target></code>		<code> bitbake -R conf/toaster.conf -r conf/toaster-bblayers.conf <target></code>
	if you have added additional toaster layers to the project or		if you have added additional toaster layers to the project or
	<code> bitbake -R conf/toaster.conf <target></code>		<code> bitbake -R conf/toaster.conf <target></code>

David Reyna: /* How to Take Over a Toaster Build Dir from the Command Line */

2018-05-23T02:56:28Z

How to Take Over a Toaster Build Dir from the Command Line

← Older revision		Revision as of 02:56, 23 May 2018
Line 19:		Line 19:
	<code> cd build-toaster-1;. <path>/poky/oe-init-build-env </code>		<code> cd build-toaster-1;. <path>/poky/oe-init-build-env </code>
	*You need to run bitbake like		*You need to run bitbake like
	<code> bitbake -R conf/toaster.conf -r conf/toaster-~~bblcass~~.conf<target></code>		<code> bitbake -R conf/toaster.conf -r conf/toaster-bblayers.conf<target></code>
	if you have added additional toaster layers to the project or		if you have added additional toaster layers to the project or
	<code> bitbake -R conf/toaster.conf <target></code>		<code> bitbake -R conf/toaster.conf <target></code>

Bavery at 23:46, 25 January 2017

2017-01-25T23:46:13Z

← Older revision		Revision as of 23:46, 25 January 2017
Line 27:		Line 27:
	* If you made a project type other than local you may run into issues since the command line build will be using the same bitbake that you started toaster from (the definition of a local project) , but if you made a past release project, this command line approach would be trying to use those layers targeted to an older release from a newer bitbake; which may or may not work.		* If you made a project type other than local you may run into issues since the command line build will be using the same bitbake that you started toaster from (the definition of a local project) , but if you made a past release project, this command line approach would be trying to use those layers targeted to an older release from a newer bitbake; which may or may not work.
	** For example, building a morty project from a master at 2.3 M2 did not work. If I wanted to set up a Morty project from toaster, I would need to start with a Morty Toaster...		** For example, building a morty project from a master at 2.3 M2 did not work. If I wanted to set up a Morty project from toaster, I would need to start with a Morty Toaster...
			** But, since the poky I started toaster from was within 100 commits of master, the master project did work...

Bavery at 23:45, 25 January 2017

2017-01-25T23:45:08Z

← Older revision		Revision as of 23:45, 25 January 2017
Line 16:		Line 16:
	A couple of caveats:		A couple of caveats:
	* You <strong>must</strong> start from a new shell, otherwise the environment variables the Toaster startup sets will cause issues.		* You <strong>must</strong> start from a new shell, otherwise the environment variables the Toaster startup sets will cause issues.
	* You need to set up the env in the new shell as if that toaster build dir were the main build dir. e.g. <code> cd build-toaster-1;. <path>/poky/oe-init-build-env </code>		* You need to set up the env in the new shell as if that toaster build dir were the main build dir. e.g.
	*You need to run bitbake like <code> bitbake -R conf/toaster.conf -r conf/toaster-bblcass.conf<target></code> if you have added additional toaster layers to the project or <code> bitbake -R conf/toaster.conf <target></code> if you have not.		<code> cd build-toaster-1;. <path>/poky/oe-init-build-env </code>
			*You need to run bitbake like
			<code> bitbake -R conf/toaster.conf -r conf/toaster-bblcass.conf<target></code>
			if you have added additional toaster layers to the project or
			<code> bitbake -R conf/toaster.conf <target></code>
			if you have not.
	* Since Toaster was not really defined for this workflow, the layers you have added are not written out to disk until a build is run from the Web ui. The smallest build you can run from the Web ui that will force all your configuration to be written to disk is quilt-native.		* Since Toaster was not really defined for this workflow, the layers you have added are not written out to disk until a build is run from the Web ui. The smallest build you can run from the Web ui that will force all your configuration to be written to disk is quilt-native.
	* If you edit the toaster*conf files by hand, and go back the the ui, it will break.		* If you edit the toaster*conf files by hand, and go back the the ui, it will break.
	* If you made a project type other than local you may run into issues since the command line build will be using the same bitbake that you started toaster from (the definition of a local project) , but if you made a past release project, this command line approach would be trying to use those layers targeted to an older release from a newer bitbake; which may or may not work.		* If you made a project type other than local you may run into issues since the command line build will be using the same bitbake that you started toaster from (the definition of a local project) , but if you made a past release project, this command line approach would be trying to use those layers targeted to an older release from a newer bitbake; which may or may not work.
	** For example, building a morty project from a master at 2.3 M2 did not work. If I wanted to set up a Morty project from toaster, I would need to start with a Morty Toaster...		** For example, building a morty project from a master at 2.3 M2 did not work. If I wanted to set up a Morty project from toaster, I would need to start with a Morty Toaster...

Bavery at 23:44, 25 January 2017

2017-01-25T23:44:07Z

← Older revision		Revision as of 23:44, 25 January 2017
Line 16:		Line 16:
	A couple of caveats:		A couple of caveats:
	* You <strong>must</strong> start from a new shell, otherwise the environment variables the Toaster startup sets will cause issues.		* You <strong>must</strong> start from a new shell, otherwise the environment variables the Toaster startup sets will cause issues.
	* You need to set up the env in the new shell as if that toaster build dir were the main build dir. e.g. <code> . <path>/poky/oe-init-build-env </code>		* You need to set up the env in the new shell as if that toaster build dir were the main build dir. e.g. <code> cd build-toaster-1;. <path>/poky/oe-init-build-env </code>
	*You need to run bitbake like <code> bitbake -R conf/toaster.conf -r conf/toaster-bblcass.conf<target></code> if you have added additional toaster layers to the project or <code> bitbake -R conf/toaster.conf <target></code> if you have not.		*You need to run bitbake like <code> bitbake -R conf/toaster.conf -r conf/toaster-bblcass.conf<target></code> if you have added additional toaster layers to the project or <code> bitbake -R conf/toaster.conf <target></code> if you have not.
	* Since Toaster was not really defined for this workflow, the layers you have added are not written out to disk until a build is run from the Web ui. The smallest build you can run from the Web ui that will force all your configuration to be written to disk is quilt-native.		* Since Toaster was not really defined for this workflow, the layers you have added are not written out to disk until a build is run from the Web ui. The smallest build you can run from the Web ui that will force all your configuration to be written to disk is quilt-native.

Bavery at 23:42, 25 January 2017

2017-01-25T23:42:45Z

← Older revision		Revision as of 23:42, 25 January 2017
Line 16:		Line 16:
	A couple of caveats:		A couple of caveats:
	* You <strong>must</strong> start from a new shell, otherwise the environment variables the Toaster startup sets will cause issues.		* You <strong>must</strong> start from a new shell, otherwise the environment variables the Toaster startup sets will cause issues.
	* ~~If you would like your command line build~~ in build~~-toaster-XX to share~~ the ~~sstate and downloads from the Toaster builds you've done proeviously, you need to run bitbake like~~ <code> . <path>/poky/oe-init-build-env; bitbake -R conf/toaster.conf <target></code>		* You need to set up the env in the new shell as if that toaster build dir were the main build dir. e.g. <code> . <path>/poky/oe-init-build-env </code>
	** If you ~~just run~~ <code> . ~~<path>/poky/oe-init-build-env; bitbake~~ <target></code> ~~it will still work but will~~ not ~~use~~ the ~~previous downloads or sstate~~.		*You need to run bitbake like <code> bitbake -R conf/toaster.conf -r conf/toaster-bblcass.conf<target></code> if you have added additional toaster layers to the project or <code> bitbake -R conf/toaster.conf <target></code> if you have not.
			* Since Toaster was not really defined for this workflow, the layers you have added are not written out to disk until a build is run from the Web ui. The smallest build you can run from the Web ui that will force all your configuration to be written to disk is quilt-native.
			* If you edit the toaster*conf files by hand, and go back the the ui, it will break.
	* If you made a project type other than local you may run into issues since the command line build will be using the same bitbake that you started toaster from (the definition of a local project) , but if you made a past release project, this command line approach would be trying to use those layers targeted to an older release from a newer bitbake; which may or may not work.		* If you made a project type other than local you may run into issues since the command line build will be using the same bitbake that you started toaster from (the definition of a local project) , but if you made a past release project, this command line approach would be trying to use those layers targeted to an older release from a newer bitbake; which may or may not work.
	** For example, building a morty project from a master at 2.3 M2 did not work. If I wanted to set up a Morty project from toaster, I would need to start with a Morty Toaster...		** For example, building a morty project from a master at 2.3 M2 did not work. If I wanted to set up a Morty project from toaster, I would need to start with a Morty Toaster...

Bavery at 22:56, 25 January 2017

2017-01-25T22:56:34Z

← Older revision		Revision as of 22:56, 25 January 2017
Line 12:		Line 12:
	</code>		</code>

	In this example, we'll assume that build-toaster-1 is a "master" project, build-toaster-2 is a "local" project, and build-toaster-3 is a "morty" project. Let's assume you've used the Toaster web ui to configure the layers and their dependencies to have what you'd like in them, but would now like to continue to do your work by hand. If you start a <strong> new </strong> shell that does not have the env variable pollution of the shell from which you started Toaster, you can do a command line build in the build-toaster-XX directory just as you normally would.		In this example, we'll assume that build-toaster-1 is a "master" project, build-toaster-2 is a "local" project, and build-toaster-3 is a "morty" project. Let's further assume you've used the Toaster web ui to configure the layers and their dependencies to have what you'd like in them, but would now like to continue to do your work by hand. If you start a <strong> new </strong> shell that does not have the env variable pollution of the shell from which you started Toaster, you can do a command line build in the build-toaster-XX directory just as you normally would.
	<br>		<br>
	A couple of caveats:		A couple of caveats:

Bavery at 22:54, 25 January 2017

2017-01-25T22:54:08Z

← Older revision		Revision as of 22:54, 25 January 2017
Line 15:		Line 15:
	<br>		<br>
	A couple of caveats:		A couple of caveats:
	* You <strong>must</strong> start from a new shell, otherwise the environment variables the Toaster startup sets will cause issues.		* You <strong>must</strong> start from a new shell, otherwise the environment variables the Toaster startup sets will cause issues.
	* If you would like your command line build in build-toaster-XX to share the sstate and downloads from the Toaster builds you've done proeviously, you need to run bitbake like <code> . <path>/poky/oe-init-build-env; bitbake -R conf/toaster.conf <target></code>		* If you would like your command line build in build-toaster-XX to share the sstate and downloads from the Toaster builds you've done proeviously, you need to run bitbake like <code> . <path>/poky/oe-init-build-env; bitbake -R conf/toaster.conf <target></code>
	** If you just run <code> . <path>/poky/oe-init-build-env; bitbake <target></code> it will still work but will not use the previous downloads or sstate.		** If you just run <code> . <path>/poky/oe-init-build-env; bitbake <target></code> it will still work but will not use the previous downloads or sstate.

	* If you made a project type other than local you may run into issues since the command line build will be using the same bitbake that you started toaster from (the definition of a local project) , but if you made a past release project, this command line approach would be trying to use those layers targeted to an older release from a newer bitbake; which may or may not work.		* If you made a project type other than local you may run into issues since the command line build will be using the same bitbake that you started toaster from (the definition of a local project) , but if you made a past release project, this command line approach would be trying to use those layers targeted to an older release from a newer bitbake; which may or may not work.
	** For example, building a morty project from a master at 2.3 M2 did not work. If I wanted to set up a Morty project from toaster, I would need to start with a Morty Toaster...		** For example, building a morty project from a master at 2.3 M2 did not work. If I wanted to set up a Morty project from toaster, I would need to start with a Morty Toaster...

Bavery at 22:52, 25 January 2017

2017-01-25T22:52:43Z

← Older revision		Revision as of 22:52, 25 January 2017
Line 12:		Line 12:
	</code>		</code>

	In this example, we'll assume that build-toaster-2 is a "master" project, build-toaster-3 is a "local" project, and build-toaster-4 is a "morty" project. Let's assume you've used the Toaster web ui to configure the layers and their dependencies to have what you'd like in them, but would now like to continue to do your work by hand. If you start a <strong> new </strong> shell that does not have the env variable pollution of the shell from which you started Toaster, you can do a command line build in the build-toaster-XX directory just as you normally would.		In this example, we'll assume that build-toaster-1 is a "master" project, build-toaster-2 is a "local" project, and build-toaster-3 is a "morty" project. Let's assume you've used the Toaster web ui to configure the layers and their dependencies to have what you'd like in them, but would now like to continue to do your work by hand. If you start a <strong> new </strong> shell that does not have the env variable pollution of the shell from which you started Toaster, you can do a command line build in the build-toaster-XX directory just as you normally would.
	<br>		<br>
	A couple of caveats:		A couple of caveats:

Bavery at 22:52, 25 January 2017

2017-01-25T22:52:17Z

← Older revision		Revision as of 22:52, 25 January 2017
Line 1:		Line 1:
	= How to Take Over a Toaster Build Dir from the Command Line =		= How to Take Over a Toaster Build Dir from the Command Line =
	Suppose you have used toaster to add layers and do some builds in a toaster ~~project~~. This results in a directory structure that could look something like:		Suppose you have used toaster to add layers and do some builds in a couple of toaster projects. This results in a directory structure that could look something like:

	<code>		<code>