title: How can I extract the environment variables used when building a recipe in Yocto?
body: <p>I am working on a kernel module for a project using Yocto Linux (version 1.3). I want to use the kernel headers and the compiler and libraries from my Yocto project, but develop the kernel module without needing to run bitbake every time. My initial solution to this was to execute the devshell task and extract the environment variables using something like this:</p>
  
  <pre><code>bitbake mykernel -c devshell
  </code></pre>
  
  <p>Then in the new xterm window bitbake opened for me:</p>
  
  <pre><code>env | sed 's/\=\(.*\)/\="\1"/' &gt; buildenv #put quotes around r-values in env listing
  ^D #(I leave the devshell)
  </code></pre>
  
  <p>Then copy this to my development directory and source it before running make with all of its options</p>
  
  <pre><code>KERNEL_PATH=/mypathto/build/tmp/sysroots/socfpga_cyclone5/usr/src/kernel
  source ./buildenv &amp;&amp; make -C $KERNEL_PATH V=1 M=`pwd` \
  ARCH=arm CROSS-COMPILE=arm-linux-gnueabihf- \
  KERNEL_VERSION=3.13.0-00298-g3c7cbb9 \
  CC="arm-linux-gnueabihf-gcc -mno-thumb-interwork -marm" \
  LD=arm-linux-gnueabihf-ld  AR=arm-linux-gnueabihf-ar
  </code></pre>
  
  <p>Now to my questions:</p>
  
  <ol>
  <li><p>Am I going about this completely wrong? What is the recommended way to cross-develop kernel modules? I am doing it this way because I don't want to open a bitbake devshell and do my code development in there every time.</p></li>
  <li><p>This sort of works (I can compile working modules) but the make script gives me an error message saying that the kernel configuration is invalid. I have also tried this with KERNEL_PATH set to the the kernel package git directory (build/tmp/work///git (which contains what appears to be a valid .config file) and I get a similar error.</p></li>
  <li><p>How can I extract the env without needing to open a devshell? I would like to write a script that extracts it so my coworkers don't have to do it manually. The devshell command opens a completely separate Xterm window, which rather dampens its scriptability...</p></li>
  </ol>