<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">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
cite="mid:CACpkpxkxAEUn2pxB6jfngwT29qT3fUKjqtSGO=pd4Vsjia53tw@mail.gmail.com"
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 moz-do-not-send="true"
href="mailto:ehsan.akhgari@gmail.com" target="_blank">ehsan.akhgari@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;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 class="h5">On Fri, Oct 17, 2014 at 11:27 AM,
Manish Goregaokar <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:manishsmail@gmail.com"
target="_blank">manishsmail@gmail.com</a>></span>
wrote:<br>
</div>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div class="h5">
<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
moz-do-not-send="true"
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
moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:firefox-dev@mozilla.org"
target="_blank">firefox-dev@mozilla.org</a><br>
<a moz-do-not-send="true"
href="https://mail.mozilla.org/listinfo/firefox-dev"
target="_blank">https://mail.mozilla.org/listinfo/firefox-dev</a><br>
<br>
</blockquote>
</div>
<span class="HOEnZb"><font color="#888888"><br>
<br clear="all">
<br>
-- <br>
<div dir="ltr">Ehsan<br>
</div>
</font></span></div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
firefox-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:firefox-dev@mozilla.org">firefox-dev@mozilla.org</a>
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/firefox-dev">https://mail.mozilla.org/listinfo/firefox-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>