Re: smartmake-like functionality has landed in mach

2013-05-04 Thread Neil

Gregory Szorc wrote:


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.


Out of interest, does the built app bundle respect the chrome format or 
does that only affect the result of make package?


--
Warning: May contain traces of nuts.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Accelerating exact rooting work

2013-05-04 Thread Boris Zbarsky

On 4/23/13 11:18 AM, Ehsan Akhgari wrote:

Can the stuff in objdir/dom/bindings be fixed whole-sale by changing the
WebIDL codegen?


This is nearly done: we're down to the issues in bug 868715, which 
largely affect the js-implemented codegen at the moment, and the problem 
of what to do with TypedArray structs.  Sadly, this last doesn't fall 
into the easy and tedious bucket.  :(


David Zbarsky has also fixed all the hazards in classinfo and a bunch 
more in various other files under dom/, so we're down to about 350 
rooting hazards in the browser, from about 2500 a week or so ago.


If people want to help out, I'm including the full list of browser 
hazards at the end of this mail.  Please comment in bug 867844 if you 
plan to fix the content/ hazards and please comment in bug 868312 if you 
plan to fix things in dom/, and in other cases file bugs blocking 
831379, just so we can avoid duplicating work.


-Boris

P.S.  Full hazard list can be found at 
http://people.mozilla.org/~sfink/analysis/browser/rootingHazards.txt and 
the list of relevant files as of this morning is:


1 hazards in js/src/jsapi-tests/testXDR.cpp
1 hazards in js/xpconnect/src/XPCConvert.cpp
1 hazards in dom/ipc/StructuredCloneUtils.cpp
1 hazards in js/src/ion/AsmJS.cpp
1 hazards in dist/include/mozilla/dom/CallbackFunction.h
1 hazards in js/xpconnect/src/XPCVariant.cpp
1 hazards in content/media/webaudio/AudioBuffer.cpp
1 hazards in dom/workers/Exceptions.cpp
1 hazards in js/src/ctypes/typedefs.h
1 hazards in dom/workers/ChromeWorkerScope.cpp
1 hazards in js/src/ion/Lowering.cpp
1 hazards in clude/molude/mozilla/dom/TypedArray.h
1 hazards in content/xul/document/src/XULDocument.cpp
1 hazards in js/src/ctypes/CTypes.cpp
1 hazards in js/src/vm/ParallelDo.cpp
1 hazards in content/base/src/EventSource.cpp
1 hazards in content/base/src/nsNodeUtils.cpp
1 hazards in js/xpconnect/src/XPCJSRuntime.cpp
1 hazards in toolkit/xre/nsEmbedFunctions.cpp
1 hazards in dist/include/mozilla/dom/BindingUtils.h
1 hazards in dom/indexedDB/IDBRequest.cpp
1 hazards in dom/indexedDB/IDBDatabase.cpp
1 hazards in clude/jslude/js/Vector.h
1 hazards in content/events/src/nsEventListenerManager.cpp
1 hazards in content/base/src/nsContentUtils.cpp
1 hazards in content/html/content/src/UndoManager.cpp
1 hazards in content/xbl/src/nsXBLSerialize.cpp
1 hazards in content/html/content/src/HTMLMediaElement.cpp
1 hazards in dom/workers/ImageData.cpp
1 hazards in dom/camera/CameraControlImpl.cpp
1 hazards in content/xslt/src/xslt/txMozillaXSLTProcessor.cpp
1 hazards in js/jsd/jsd_obj.cpp
1 hazards in content/events/src/nsEventListenerService.cpp
1 hazards in security/manager/ssl/src/nsCrypto.cpp
1 hazards in content/html/content/src/nsGenericHTMLElement.cpp
1 hazards in tools/profiler/TableTicker.cpp
1 hazards in js/xpconnect/src/nsDOMQS.h
1 hazards in content/xul/document/src/nsXULPrototypeDocument.cpp
1 hazards in js/xpconnect/src/XPCQuickStubs.cpp
1 hazards in content/xbl/src/nsXBLBinding.cpp
1 hazards in widget/xpwidgets/GfxInfoBase.cpp
1 hazards in js/xpconnect/src/XPCQuickStubs.h
1 hazards in content/xbl/src/nsXBLDocumentInfo.cpp
1 hazards in toolkit/components/telemetry/Telemetry.cpp
1 hazards in dom/camera/DOMCameraControl.cpp
1 hazards in content/base/src/nsInProcessTabChildGlobal.h
1 hazards in dom/mobilemessage/src/ipc/SmsIPCService.cpp
1 hazards in js//inclst/include/mozilla/dom/workers/bindings/EventTarget.h
1 hazards in dom/indexedDB/IndexedDatabaseManager.cpp
1 hazards in dist/include/mozilla/dom/EventListenerBinding.h
1 hazards in content/base/src/nsContentList.cpp
1 hazards in content/canvas/src/CanvasUtils.h
1 hazards in storage/src/mozStorageAsyncStatementParams.cpp
1 hazards in js/src/vm/Shape.cpp
1 hazards in tools/profiler/ProfileEntry.cpp
1 hazards in content/base/src/nsDOMBlobBuilder.cpp
1 hazards in dom/mobilemessage/src/SmsManager.cpp
1 hazards in clude/molude/mozilla/jsipc/ContextWrapperChild.h
1 hazards in dom/file/ArchiveRequest.cpp
1 hazards in content/html/document/src/nsHTMLDocument.cpp
1 hazards in content/base/src/nsDocument.h
1 hazards in js/src/ion/IonCaches.cpp
1 hazards in content/xul/content/src/nsXULElement.cpp
1 hazards in js/src/vm/Debugger.cpp
1 hazards in dom/base/DOMRequest.cpp
2 hazards in dom/network/src/TCPSocketChild.cpp
2 hazards in dom/system/OSFileConstants.cpp
2 hazards in content/xul/document/src/nsXULPrototypeCache.cpp
2 hazards in content/base/src/nsXMLHttpRequest.cpp
2 hazards in dom/devicestorage/nsDeviceStorage.cpp
2 hazards in storage/src/mozStorageStatementParams.cpp
2 hazards in content/base/src/WebSocket.cpp
2 hazards in storage/src/mozStorageStatementRow.cpp
2 hazards in js/jsd/jsd_stak.cpp
2 hazards in content/xul/templates/src/nsXULTemplateBuilder.cpp
2 hazards in js/src/jswrapper.cpp
3 hazards in tools/profiler/JSObjectBuilder.cpp
3 hazards in dom/workers/EventTarget.cpp
3 hazards in js/xpconnect/src/XPCWrappedNative.cpp
3 hazards in dist/include/nsTArrayHelpers.h
3 hazards in 

Re: Proposal for an inbound2 branch

2013-05-04 Thread Justin Dolske

On 5/1/13 8:41 PM, Ehsan Akhgari wrote:

Another disadvantage of project branches in addition to the ones
mentioned before is that it limits/delays the amount of testing that you
can get on Nightly and from all of the developers who run things like
fuzzers on ours code.  Not everyone's project has enough manpower to get
that level of testing on a project branch before their stuff gets merged
to central/inbound.  I personally cannot imagine doing my development in
a project branch silo and deprive myself of the huge advantage that this
kind of testing brings about.


That all depends on how one uses a project branch.

If you use a project branch as a traditional staging area for work that 
is large/complex and merge it infrequently, then yes. Those are 
absolutely real problems.


But if you use a project branch as just a frequently-merged integration 
branch, then I don't see these things as being problems. I think that's 
what gps is proposing -- not the old-school usage of project branches 
(maybe we need a new term?). Such branches would be almost exactly the 
same thing as mozilla-inbound, and we don't worry about those problems 
on inbound. We did exactly this in the past with JS and Services (and to 
a lesser extent with fx-team)... We'd just call them inbound-js and 
inbound-services now.


[AIUI, those teams stopped because inbound was working so well -- why 
spend time running your own branch when m-i is just as good and requires 
no effort? The twist now is that m-i is a victim of it's own success, 
and so we should think about making the costs more directly visible to 
project teams.]


Justin
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform