<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Tue, Oct 21, 2014 at 10:55 PM, Aaron Klotz <span dir="ltr"><<a href="mailto:aklotz@mozilla.com" target="_blank">aklotz@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    From the Desktop Perf team's perspective, my concern would be that
    we'd miss regressions relating to omnijar generation itself.<br>
    <br>
    We have a readahead performance optimization that is applied to the
    omnijar in PGO builds. In the past we've seen cases where this
    optimization is inadvertently disabled by a patch. I'd rather know
    about any such bustage before it makes its way to Aurora.<span class=""><font color="#888888"><br>
    <br></font></span></div></blockquote><div><br>The idea is to have a <i>different</i> Nightly build for Fx contributors to download. This won't affect the tinderboxes, or the regular build at <a href="http://nightly.mozilla.com">nightly.mozilla.com</a>.<br><br clear="all"><div><div dir="ltr">-Manish Goregaokar</div></div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span class=""><font color="#888888">
    - Aaron</font></span><div><div class="h5"><br>
    <br>
    <br>
    <div>On 10/17/14 10:47 AM, Gijs Kruitbosch
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div>If we decide to go this route, we
        should really ensure that this is not the default configuration,
        or we'll all have broken tests on aurora to look forward to
        (I've seen tests work against flat chrome but not against
        omni.ja, depending on how much introspection they end up doing
        and/or how they set paths and such).<br>
        <br>
        Also, even if we did this, we'd still need a way to get the
        patches to work, esp. what with preprocessing and such (for most
        of our front-end JS and CSS), they just won't apply (and will be
        in the wrong format etc. etc.). Plus folks would have to turn
        off xul cache in order for things to work reliably after a
        restart.<br>
        <br>
        Generally, I'm conflicted about this idea: it's fairly
        low-hanging to implement, but it's still pretty kludgy, and it
        will encourage more kludginess to make it work "better".<br>
        <br>
        On the other hand, doing something that feels neater (e.g.:
        create an m-c clone with just the (non-compiled/c++/c) contents
        of toolkit/ and browser/, keep it in sync with m-c every day,
        and maintain a build script that can rebuild just these files
        into the omni.ja file/gredir for an existing build) will require
        more engineering investment.<br>
        <br>
        I'm not sure where the right tradeoff is. While they're not
        mutually exclusive, I worry that choosing kludginess now will
        have us stuck with it even if/when we get better solutions.<br>
        <br>
        ~ Gijs<br>
        <br>
        On 17/10/2014 09:32, Manish Goregaokar wrote:<br>
      </div>
      <blockquote type="cite">
        <div dir="ltr">Yeah, but to do any kind of <i>building</i> we
          still need a build system and an initial build, which takes
          forever to set up. I'm proposing we distribute nightly
          binaries with the omni.ja stuff flat.<br>
        </div>
        <div class="gmail_extra"><br clear="all">
          <div>
            <div dir="ltr">-Manish Goregaokar</div>
          </div>
          <br>
          <div class="gmail_quote">On Fri, Oct 17, 2014 at 9:23 PM,
            Ehsan Akhgari <span dir="ltr"><<a href="mailto:ehsan.akhgari@gmail.com" target="_blank">ehsan.akhgari@gmail.com</a>></span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
              <div dir="ltr">Wouldn't building with
                --enable-chrome-format=flat give you what you want? 
                That option at least used to avoid creating the omni.ja
                package altogether and instead put normal files in your
                objdir which you could edit and restart Firefox to see
                the affects of (while of course getting rid of the XUL
                cache, etc.)<br>
              </div>
              <div class="gmail_extra"><br>
                <div class="gmail_quote">
                  <div>
                    <div>On Fri, Oct 17, 2014 at 11:27 AM,
                      Manish Goregaokar <span dir="ltr"><<a href="mailto:manishsmail@gmail.com" target="_blank">manishsmail@gmail.com</a>></span>
                      wrote:<br>
                    </div>
                  </div>
                  <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
                    <div>
                      <div>
                        <div dir="ltr">
                          <div>
                            <div>Many contributors only stick to editing
                              js/css/XUL. They don't really <i>need</i>
                              a full build system for this, since these
                              files are dynamically loaded at runtime.<br>
                              <br>
                              However, these files are stored in the two
                              omni.ja files. It's both <a href="https://developer.mozilla.org/en-US/docs/Mozilla/About_omni.ja_%28formerly_omni.jar%29" target="_blank">hard to extract that
                                file, and hard to compress it</a>
                              (perhaps impossible on Windows?). It's
                              also <a href="http://inpursuitoflaziness.blogspot.in/2014/01/editing-files-from-omnija-in-firefox-20.html" target="_blank">completely non intuitive
                                how to instruct Firefox to reload the
                                file after editing</a>.<br>
                              <br>
                            </div>
                            Would it be possible to provide nightlies of
                            Firefox with unpacked omni.ja files without
                            the js binaries? (Even better, have the
                            files in the same directory structure as the
                            original source)<br>
                          </div>
                          <div>It would really improve the
                            getting-started curve since new contributors
                            can start tinkering without having to wait
                            for a build.<br>
                            <br>
                          </div>
                          <div>mhoye had come up with this idea in a
                            past thread where we were discussing startup
                            hurdles, I just remembered it now when I
                            needed to test something on Windows without
                            a build system (another benefit of this --
                            UI patches can be tested and tweaked without
                            a build system)<span><font color="#888888"><br>
                              </font></span></div>
                          <span><font color="#888888">
                              <div><br clear="all">
                                <div>
                                  <div>
                                    <div>
                                      <div dir="ltr">-Manish Goregaokar</div>
                                    </div>
                                  </div>
                                </div>
                              </div>
                            </font></span></div>
                        <br>
                      </div>
                    </div>
                    _______________________________________________<br>
                    firefox-dev mailing list<br>
                    <a href="mailto:firefox-dev@mozilla.org" target="_blank">firefox-dev@mozilla.org</a><br>
                    <a href="https://mail.mozilla.org/listinfo/firefox-dev" target="_blank">https://mail.mozilla.org/listinfo/firefox-dev</a><br>
                    <br>
                  </blockquote>
                </div>
                <span><font color="#888888"><br>
                    <br clear="all">
                    <br>
                    -- <br>
                    <div dir="ltr">Ehsan<br>
                    </div>
                  </font></span></div>
            </blockquote>
          </div>
          <br>
        </div>
        <br>
        <fieldset></fieldset>
        <br>
        <pre>_______________________________________________
firefox-dev mailing list
<a href="mailto:firefox-dev@mozilla.org" target="_blank">firefox-dev@mozilla.org</a>
<a href="https://mail.mozilla.org/listinfo/firefox-dev" target="_blank">https://mail.mozilla.org/listinfo/firefox-dev</a>
</pre>
      </blockquote>
      <br>
      <br>
      <fieldset></fieldset>
      <br>
      <pre>_______________________________________________
firefox-dev mailing list
<a href="mailto:firefox-dev@mozilla.org" target="_blank">firefox-dev@mozilla.org</a>
<a href="https://mail.mozilla.org/listinfo/firefox-dev" target="_blank">https://mail.mozilla.org/listinfo/firefox-dev</a>
</pre>
    </blockquote>
    <br>
  </div></div></div>

<br>_______________________________________________<br>
firefox-dev mailing list<br>
<a href="mailto:firefox-dev@mozilla.org">firefox-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/firefox-dev" target="_blank">https://mail.mozilla.org/listinfo/firefox-dev</a><br>
<br></blockquote></div><br></div></div>