[webkit-dev] JavaScriptCore directory rearrangement proposal

2008-06-16 Thread Maciej Stachowiak 


Here is a proposal for how to rearrange the directory structure of  
JavaScriptCore and move some files around. Comments welcome. First,  
here's the new proposed directories:

JavaScriptCore/
 api/
 impl/
 compiler/
 docs/
 os-win32/
 parser/
 pcre/
 runtime/
 vm/
 tools/
 tests/
 api/
 mozilla/
 ...
 wtf/
 gtk/
 mac/
 qt/
 win/
 wx/
 unicode/
icu/
qt4/

I wasn't sure where to move these files but I believe they can be  
removed:
 types.h
 LocalStorageEntry.h

I'm not sure where to put these:
 ExecState.cpp (runtime or vm?)
 ExecState.h
 completion.h (only used in interpreter.h)
 interpreter.cpp (this does not fit well into any of our  
categories - perhaps these should become non-static methods on  
JSGlobalObject)
 interpreter.h
 SymbolTable.h (runtime or compiler?)

Where specific files would go:

top level
 AllInOneFile.cpp
 config.h
 Shell.cpp

wtf/
 (contents unchanged)

pcre/
 (contents unchanged)

api/
 JavaScript.h
 JavaScriptCore.h
 JSBase.h
 JSContextRef.h
 JSObjectRef.h
 JSStringRef.h
 JSStringRefCF.h
 JSValueRef.h
 WebKitAvailability.h

api/impl/
 APICast.h
 JSBase.cpp
 JSCallbackConstructor.cpp
 JSCallbackConstructor.h
 JSCallbackFunction.cpp
 JSCallbackFunction.h
 JSCallbackObject.cpp
 JSCallbackObject.h
 JSCallbackObjectFunctions.h
 JSClassRef.cpp
 JSClassRef.h
 JSContextRef.cpp
 JSObjectRef.cpp
 JSRetainPtr.h
 JSStringRef.cpp
 JSStringRefCF.cpp
 JSValueRef.cpp


runtime/
 ArrayPrototype.cpp
 ArrayPrototype.h
 BooleanObject.cpp
 BooleanObject.h
 CallData.h
 collector.cpp
 collector.h
 CollectorHeapIntrospector.cpp
 CollectorHeapIntrospector.h
 CommonIdentifiers.cpp
 CommonIdentifiers.h
 ConstructData.h
 create_hash_table
 date_object.cpp
 date_object.h
 DateMath.cpp
 DateMath.h
 dtoa.cpp
 dtoa.h
 error_object.cpp
 error_object.h
 FunctionPrototype.cpp
 FunctionPrototype.h
 identifier.cpp
 identifier.h
 InitializeThreading.cpp
 InitializeThreading.h
 internal.cpp
 JSActivation.cpp
 JSActivation.h
 JSArray.cpp
 JSArray.h
 JSFunction.cpp
 JSFunction.h
 JSGlobalData.cpp
 JSGlobalData.h
 JSGlobalObject.cpp
 JSGlobalObject.h
 JSImmediate.cpp
 JSImmediate.h
 JSLock.cpp
 JSLock.h
 JSNotAnObject.cpp
 JSNotAnObject.h
 JSObject.cpp
 JSObject.h
 JSPropertyNameIterator.cpp
 JSPropertyNameIterator.h
 JSString.h
 JSType.h
 JSValue.cpp
 JSValue.h
 JSVariableObject.cpp
 JSWrapperObject.cpp
 JSWrapperObject.h
 list.cpp
 list.h
 lookup.cpp
 lookup.h
 MathObject.cpp
 MathObject.h
 NumberObject.cpp
 NumberObject.h
 object_object.cpp
 object_object.h
 operations.cpp
 operations.h
 PropertyMap.cpp
 PropertyMap.h
 PropertyNameArray.cpp
 PropertyNameArray.h
 PropertySlot.cpp
 PropertySlot.h
 protect.h
 regexp.cpp
 regexp.h
 RegExpObject.cpp
 RegExpObject.h
 ScopeChain.cpp
 ScopeChain.h
 ScopeChainMark.h
 string_object.cpp
 string_object.h
 ustring.cpp
 ustring.h

parser/
 grammar.y
 keywords.table
 lexer.cpp
 lexer.h
 nodes.cpp (but split out emitCode functions and move to compiler  
directory)
 nodes.h
 nodes2string.cpp
 Parser.cpp
 Parser.h
 SourceProvider.h
 SourceRange.h

compiler/
 CodeGenerator.cpp
 CodeGenerator.h
 LabelID.cpp
 LabelID.h
 LabelStack.h
 RegisterID.cpp
 RegisterID.h
 SegmentedVector.h

vm/
 CodeBlock.cpp
 CodeBlock.h
 ExceptionHelpers.cpp
 ExceptionHelpers.h
 Instruction.cpp
 Instruction.h
 Machine.cpp
 Machine.h
 Opcode.cpp
 Opcode.h
 Register.cpp
 Register.h
 RegisterFile.cpp
 RegisterFile.h
 RegisterFileStack.cpp
 RegisterFileStack.h

tools/
 debugger.cpp
 debugger.h
 DebuggerCallFrame.cpp
 DebuggerCallFrame.h
 Profile.cpp
 Profile.h
 ProfileNode.cpp
 ProfileNode.h
 Profiler.cpp
 Profiler.h

tests/api/
 JSNode.c
 JSNode.h
 JSNodeList.c
 JSNodeList.h
 minidom.c
 minidom.js
 Node.c
 Node.h
 NodeList.c
 NodeList.h
 testapi.c
 testapi.js

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] JavaScriptCore directory rearrangement proposal

2008-06-16 Thread Sam Weinig 
It has always bugged me that WTF was in JavaScriptCore at all.  Perhaps now
is a good time to move it to its own project. I am not sure what the
concerns in the past were about separating WTF from JavaScriptCore.  Were
they performance related?
-Sam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] JavaScriptCore directory rearrangement proposal

2008-06-16 Thread Geoffrey Garen 
 I'm not sure where to put these:
 ExecState.cpp (runtime or vm?)
 ExecState.h

I like vm. Mostly, an ExecState represents the state of execution in  
the VM. The runtime relies on the ExecState, but I wouldn't say that  
the ExecState was a component of the runtime.

 completion.h (only used in interpreter.h)
 interpreter.cpp (this does not fit well into any of our
 categories - perhaps these should become non-static methods on
 JSGlobalObject)
 interpreter.h

If this stuff belongs with JSGlobalObject, let's put it in runtime,  
since that's where JSGlobalObject lives.

 SymbolTable.h (runtime or compiler?)

I like compiler. Same argument as with ExecState.

 Shell.cpp

How about calling this jsc.cpp, if it's the jsc executable?

 WebKitAvailability.h

Hmmm... Why is this in JavaScriptCore at all? It's not used there.

Geoff
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] JavaScriptCore directory rearrangement proposal

2008-06-16 Thread Mark Rowe 


On 16/06/2008, at 18:49, Geoffrey Garen wrote:


   WebKitAvailability.h


Hmmm... Why is this in JavaScriptCore at all? It's not used there.


It's not used there *yet*.  If new API is added to JavaScriptCore then  
they need to be tagged with the availability macros.  Rather than  
having a separate set of macros for JavaScriptCore than WebKit, we  
decided to put the header at the JavaScriptCore level instead.


- Mark



smime.p7s
Description: S/MIME cryptographic signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev