<div dir="ltr">On Mon, Apr 29, 2013 at 2:47 PM, Behan Webster <span dir="ltr">&lt;<a href="mailto:behanw@converseincode.com" target="_blank">behanw@converseincode.com</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">



<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF"><div>
    <div>On 13-04-29 02:22 PM, Eduard Bachmakov
      wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">Hey Mark,<br>
        <div class="gmail_extra"><br>
          <div class="gmail_quote">On Sun, Apr 28, 2013 at 10:49 AM,
            Mark Charlebois <span dir="ltr">&lt;<a href="mailto:charlebm@gmail.com" target="_blank">charlebm@gmail.com</a>&gt;</span> wrote:
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div>The build system tries to keep as much common as
                possible while allowing you to do the following:</div>
              <div><br>
              </div>
              <div>- add new targets</div>
              <div>- write common rules of targets of the same
                architecture</div>
              <div>- write patches that are common, arch specific or
                target specific, or git branch specific (for particular
                kernel versions as some targets do not tract the
                upstream trunk)</div>
              <div>- support multiple cross toolchains to validate using
                clang with particular assemblers and linkers</div>
              <div>- switching the toolchain to use with clang is as
                simple as changing a line in the target makefile</div>
              <div>
                - provide easy commands to do common tasks: syncing,
                building at target or rebuilding clang, etc</div>
            </blockquote>
            <div><br>
            </div>
            <div>So if I understand this right, the system is a set of
              hand-written Makefiles (as opposed to systems like cmake
              or autotools)?</div>
          </div>
        </div>
      </div>
    </blockquote></div>
    Think of it more like a set of scripts used to drive Kbuild and
    cmake used by the code bases we are using. Make is the glue; IMHO
    neither cmake nor autotools are the right tools for this kind of
    thing.<br>
    <br>
    You can think of our build system as a test harness or a meta-build
    system.</div></blockquote><div><br></div><div>I see. Makes sense. I was just wondering if the Makefiles are generated automatically or written by hand. From the two responses (and the pretty-ness of the markup inside of them) I gather it&#39;s the latter. </div>



<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><div>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div>cd llvmlinux</div>
              <div>
                make build-dep-check</div>
              <div><br>
              </div>
              <div>-- install anything missing --</div>
              <div><br>
              </div>
              <div>cd target/vexpress</div>
              <div><br>
              </div>
              <div>make kernel-build</div>
            </blockquote>
            <div><br>
            </div>
            <div>I was able to x64 just fine the other day. (I also
              tried it with allyesconfig but that (obviously) failed).</div>
          </div>
        </div>
      </div>
    </blockquote></div>
    We don&#39;t support all configurations yet. Getting to the point where
    we are already has taken a lot of work already.</div></blockquote><div><br></div><div>I understand. It was also on of the ideas on the GSoC page to have allyesconfig work. I was just curious how long until the error (longer than I expected; it was a VLAS).</div>



<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><div>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div>Quick question though, why is vexpress always used as
              an example (buildbot, wiki, etc)? Is there something
              special about it or &quot;just because&quot;?</div>
          </div>
        </div>
      </div>
    </blockquote></div>
    It&#39;s the reference embedded ARM architecture, is well supported in
    QEMU, as well as being available as real HW. It&#39;s the go-to target
    for this kind of thing.</div></blockquote><div><br></div><div>I see.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
<div>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div>This will download LLVM and clang and build them,
                download the cross compiler toolchains specified in the
                vexpress Makefile, download the kernel, and then build
                the kernel, apply the patches to the kernel and build
                the kernel with clang. </div>
              <div><br>
              </div>
              <div>The build system tracks all of the dependencies in
                state subdirectories. When you clean a particular make
                target it will clean out the files from the associated
                state directory.</div>
            </blockquote>
            <div>
               </div>
            <div>About the state directories: I noticed the files are
              empty. I assume you&#39;re testing for state using test -f
              like methods?</div>
          </div>
        </div>
      </div>
    </blockquote></div>
    The state directories are for build stamp files. Files which
    indicate the entering of a successful state of a part of the code
    base. It&#39;s a common practice in using Makefiles on large projects to
    speed things up.<div><br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div>As far as the scope for implementing checker for the
                kernel, many of the frequent contributors just have not
                had the time to try it. From those who have tried it, we
                know it doesn&#39;t just work out of the box.  </div>
            </blockquote>
            <div><br>
            </div>
            <div>I see. When ever I used the analyzer it was using the
              scan-build tool. Need to check whether it works with the
              custom build system</div>
          </div>
        </div>
      </div>
    </blockquote></div>
    We don&#39;t need to run it on our makefiles. We need it run on the
    kernel makefiles (Kbuild). The analyzer would be driven by our build
    system.</div></blockquote><div><br></div><div>The way I understand the system, it basically replaces env variables but allows customization, does error-handling, sets defaults, etc. I was just wondering if it would propagate through down to where the `make` that actually builds the kernel.</div>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><div><blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div>Its an advanced task because the kernel make system
                is complcated, and it may require modifying LLVM or
                checker code. We just don&#39;t know yet. </div>
            </blockquote>
            <div><br>
            </div>
            <div>Alright. My plan was to read up on the whole kbuild
              system and see how flags/commands enabling the analyzer
              would be integrated.</div>
          </div>
        </div>
      </div>
    </blockquote></div>
    The idea isn&#39;t to integrate it into the kernel build system. We want
    to run it against the kernel build. So updates to the analyzer to
    support the kernel would be the ideal situation.</div></blockquote><div><br></div><div>I don&#39;t think I quite understand what you mean here. The analyzer itself is -- afaik -- the &quot;--analyze&quot; flag to clang (+ whatever &quot;sub&quot;-flags there are). Could you please elaborate?</div>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><div>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div>Thanks for your interest in the project!</div>
            </blockquote>
            <div><br>
            </div>
            <div>Let&#39;s hope I can help :-).</div>
            <br>
          </div>
        </div>
      </div>
    </blockquote></div>
    We would welcome your assistance!<span><font color="#888888"><br>
    <br>
    Behan</font></span></div></blockquote><div><br></div><div>:-)</div><div><br></div><div style>Eduard </div></div></div></div>