**** BEGIN LOGGING AT Wed May 10 03:00:00 2017 May 10 11:05:38 hey May 10 11:08:07 how can i specify SYSLINUX_ROOT for a specific IMAGE_FSTYPES value? May 10 11:17:18 i want to use SYSLINUX_ROOT_qemux86-64 = "root=/dev/vda2" for qcow2 but do not set a special value for vdi May 10 11:19:43 i still do not really understand what I can append to variable definitions to make them more specific May 10 11:20:19 could i simply set SYSLINUX_ROOT_qemux86-64_vdi? neither do i understand why I could do that or why not May 10 13:20:40 there is no common sysroots folder anymore? May 10 13:46:27 recipe specific sysroots (RSS) May 10 13:47:10 dv_: correct, master has done away with it May 10 13:47:17 dv_: yay reliability May 10 13:47:31 each build has exactly what it asked for in the sysrot May 10 13:47:33 that ... is inconvenient for me May 10 13:47:42 if I do an out-of-tree cross build May 10 13:48:03 that's what an sdk is for :) May 10 13:48:07 the external-sdk is cumbersome to use if I also have to change OE recipes/configs during development May 10 13:48:18 every time I have to rebuild and redeploy the entire sdk May 10 13:48:35 externalsrc.bbclass? May 10 13:49:29 requires a recipe for my unfinished code + rebuilds it every time May 10 13:49:53 the two best options I found so far : devtool (but only if there is already a recipe) and devshell with a dummy package May 10 13:50:25 like bitbake -c devshell screen (I dont really want to build screen, but the shell that is produced has env vars like CC and PATH set up) May 10 13:50:34 ideally there would be bitbake-scratchbox May 10 13:51:42 I mean, imagine I am developing something in https://github.com/Freescale/gstreamer-imx . what I was doing till now: working in my local cloned git repo, then I ran a script that set up CC, PATH etc. to point to the sysroot of yocto, then I ran ./waf configure May 10 13:52:34 the externalsdk is useful here - but only if I dont have to modify anything in yocto May 10 13:53:20 dv_: there's a task that populates the sysroot for a given recipe May 10 13:53:29 any workflow that requires me to write a recipe first is suboptimal. I want to develop it first, then i can worry about writing a recipe May 10 13:53:33 so you could run that for such a recipe an duse its sysroot May 10 13:53:37 dv_: bitbake build-sysroots May 10 13:53:38 for this stuff, maemo's scratchbox was awesome May 10 13:53:54 it was pretty much like -c devshell except that it did not require any recipe name May 10 13:54:12 if I typed "gcc", it ran the cross compiler gcc etc. May 10 13:54:48 could always install a target toolchain in a qemu rootfs and do native development in qemu ;) May 10 13:54:57 not as slow as it used to be May 10 13:55:04 particularly if you were to set up distcc back to the host May 10 13:55:08 * kergoth shrugs May 10 13:55:32 yeah ... oh and thanks for build-sysroots, didnt know that May 10 13:55:48 I just want to highlight that requiring a recipe for development is not a good idea May 10 13:56:38 imagine you are developing a new piece of software, and want to run it on a board. right now, either you write a script like I did for setting up env vars, or you write an OE recipe and then populate the sysroot for it (or use devshell, or devtool) May 10 13:56:54 or use the sdk May 10 13:57:05 or that - if you dont have to change anything in yocto May 10 13:57:45 with eSDK you can at least update the SDK from shared-state objects, rather than having to create a whole new SDK and install it from scratch May 10 13:57:45 so, just tossing around an idea, something like a bitbake-scratchbox perhaps.. May 10 13:58:00 please file an enhancement request in YP bugzilla :-) May 10 13:58:07 will do May 10 13:58:07 see you say scratchbox and i start getting an itch in the back of my neck May 10 13:58:13 and a twitch in my eye May 10 13:58:18 rburton: not exactly like the maemo scratchbox May 10 13:58:22 just the principles May 10 14:01:03 when you propose a bitbake-scratchbox, my first question is *exactly what will it build first?* which packages will be built and available in the sysroot provided for it? if you have to specify that anyway, then you can specify it in a recipe and use the recipe's sysroot instead :) May 10 14:01:27 admittedly slightly indirect, the updating the esdk method sounds better May 10 14:11:19 dv_: the paint point is valid, but I'm not sure how you get around defining the 'default' somewhere. Essentially, that's what the e-sdk is, right? **** ENDING LOGGING AT Thu May 11 03:00:01 2017