On 5/3/2013 11:19 AM, Reuben Morais wrote:
You can also use |ac_add_options --with-chrome-format=symlink| to do something
similar for the chrome JAR, it doesn't work with stuff that is preprocessed,
but greatly reduces the number of files that require rebuildling browser/app
when changed.
Perhaps you aren't aware that --with-chrome-format=symlink was
deprecated in bug 855227? IIRC that option became moot with the packager
rewrite a few months back.
On 5/3/2013 12:21 AM, Mike Hommey wrote:
On Fri, May 03, 2013 at 02:55:09AM -0400, Ehsan Akhgari wrote:
If you run from dist/bin, it's not required. It is if you run
dist/Nightly.app or whatever it's called. It's also required for make
package to work.
Last I checked you couldn't run from dist/bin on OSX as running an app
outside of an app bundle breaks lots of things.
And this is why we have things like |mach run|. That command makes
intelligent choices for you so you don't fall into these kinds of traps.
As an aside, instead of conversing (I dare say spreading inaccuracies)
about what is or is not required to build/run/whatever, let's focus our
energy on making things "just work." Developers should not be concerned
over what combinations of mozconfig options and directories need to be
built. Ideally you just type |mach build| to ensure the tree is up to
date. Actually, if you type |mach run| it should probably build the tree
for you. But given no-op builds currently take "way too long," I realize
why this isn't feasible. That's why I'm OK with smartmake/dumbmake being
in the tree despite that it undermines/works around the build system proper.
Until a |mach build| no-op (or at least very small op) is fast enough to
be part of the developer workflow, let's patch dumbmake so |mach build
X| is all that is needed to yield a working XUL app binary. This will
make everyone's lives easier.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
