On Tue, 2017-11-14 at 10:09 -0600, Leonardo Sandoval wrote: > On Tue, 14 Nov 2017 09:24:30 +0100 > Patrick Ohly <patrick.o...@intel.com> wrote: > > > On Mon, 2017-11-13 at 10:17 -0800, > > leonardo.sandoval.gonza...@linux.intel.com wrote: > > > From: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.c > > > om> > > > > > > The main idea is to isolate the oe-selftest execution so neither > > > the > > > current build dir nor the configuration data is touch/polluted. > > > This > > > approach uses a wrapper script (which is the one presented on > > > this > > > commit) which creates a unique directory and inside it copies all > > > scripts and metadata, re-initializes the enviroment (re-sources > > > oe- > > > init-build-env) and finally launches the oe-selftest-internal > > > (which > > > used to be oe-selftest) command, passing command arguments to the > > > latter. > > > > This mode of operation may or may not be desirable. Can it be made > > optional? > > good idea. However, you can call the oe-selftest-internal for the > this purpose.
While doable, it feels wrong to rename something as "internal" and then still expect people to call it directly. A command line parameter for the new oe-selftest which controls this behavior and just calls oe-selftest-internal directly when requested feels cleaner and more discoverable. Is oe-selftest-internal even going to be in the default PATH? It probably shouldn't be, once it truly becomes an implementation detail. > > In refkit CI testing, several selftests run tests on build > > artifacts > > (primarily the images) produced during the previous build and only > > build them if needed, i.e. they run "bitbake some-image" and that > > is > > usually fast because the image already exists. Reusing sstate and > > download dir also is important for speed. > > oe-selftest creates a new build/conf folder, with the same conf files > as the ones present in your current build/conf, so this means that > you can set there DL_DIR and SSTATE_DIR (for example) on your main > local.conf and these will be used by oe-selftest, effectively reusing > these folders. Instead of leaving it to the developer to figure this out, should the oe-selftest have --[no-]reuse-download and --[no]-reuse-sstate options? > > -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core