Move systems creation to dartdomgenerator.py.

Move systems creation to dartdomgenerator.py.

Wrapperless htmldartium system should use a database with html renames
for interface generation, and original database for c++ code generation.
This is hard to achieve with current layout because specific knowledge about html/dom
and frog/native is spread between dartdomgenerator and dartgenerator.

This patch moves all system creation logic to dartdomgenerator while dartgenerator
becomes a collection of helper methods for traversing idl database.

R=antonm@google.com,sra@google.com

Committed: https://code.google.com/p/dart/source/detail?r=7739

[Anton Muhin, 2012-05-17 15:46:24]

My main concern: with this change the build will apparently become slower: we'll
reread database for each system, etc.  This greatly reduces hackability.  Can we
do something about it in this CL?

https://chromiumcodereview.appspot.com/10392147/diff/1/lib/dom/scripts/dartdo...
File lib/dom/scripts/dartdomgenerator.py (right):

https://chromiumcodereview.appspot.com/10392147/diff/1/lib/dom/scripts/dartdo...
lib/dom/scripts/dartdomgenerator.py:17: from systembase import *
do we care about more specific imports?

https://chromiumcodereview.appspot.com/10392147/diff/1/lib/dom/scripts/dartdo...
lib/dom/scripts/dartdomgenerator.py:82: auxiliary_dir=os.path.join(current_dir,
'..', 'src')
nit: spaces around = here and below

[podivilov, 2012-05-17 17:44:01]

I lifted database processing out of the loop. Now generation speed is exactly
the same as before.

https://chromiumcodereview.appspot.com/10392147/diff/1/lib/dom/scripts/dartdo...
File lib/dom/scripts/dartdomgenerator.py (right):

https://chromiumcodereview.appspot.com/10392147/diff/1/lib/dom/scripts/dartdo...
lib/dom/scripts/dartdomgenerator.py:17: from systembase import *
On 2012/05/17 15:46:24, antonmuhin wrote:
> do we care about more specific imports?

Done.

https://chromiumcodereview.appspot.com/10392147/diff/1/lib/dom/scripts/dartdo...
lib/dom/scripts/dartdomgenerator.py:82: auxiliary_dir=os.path.join(current_dir,
'..', 'src')
On 2012/05/17 15:46:24, antonmuhin wrote:
> nit: spaces around = here and below

Done.

[Anton Muhin, 2012-05-17 18:05:38]

Almost there

https://chromiumcodereview.appspot.com/10392147/diff/8/lib/dom/scripts/dartdo...
File lib/dom/scripts/dartdomgenerator.py (right):

https://chromiumcodereview.appspot.com/10392147/diff/8/lib/dom/scripts/dartdo...
lib/dom/scripts/dartdomgenerator.py:116: output_dir = os.path.join(current_dir,
'../../html/generated')
that will overwrite output_dir for other systems, correct?

[podivilov, 2012-05-17 18:20:36]

PTAL.

https://chromiumcodereview.appspot.com/10392147/diff/8/lib/dom/scripts/dartdo...
File lib/dom/scripts/dartdomgenerator.py (right):

https://chromiumcodereview.appspot.com/10392147/diff/8/lib/dom/scripts/dartdo...
lib/dom/scripts/dartdomgenerator.py:116: output_dir = os.path.join(current_dir,
'../../html/generated')
On 2012/05/17 18:05:38, antonmuhin wrote:
> that will overwrite output_dir for other systems, correct?

Thanks for spotting this!

[Anton Muhin, 2012-05-17 18:31:02]

lgtm

[sra1, 2012-05-18 20:29:20]

Prior to this change I could run the generator with ALL possible systems.

I find that capability essential - I can diff the ../generated directory and see
if the change has unexpected effects on the other systems.

Please can we keep that capability?
I find it very difficult to work without it.

Is there anything other than changing the if-then-else to prevent this?

[sra1, 2012-05-18 20:49:24]

On 2012/05/17 15:46:24, antonmuhin wrote:
> My main concern: with this change the build will apparently become slower:
we'll
> reread database for each system, etc.  This greatly reduces hackability.  Can
we
> do something about it in this CL?

This is my concern too.  For example, this CL has stalled my work on the
dispatch as I have to adjust my process.
It is my fault for not sharing my process with you earlier.
We need to have a one-stop generate-everything, even if it re-reads the
database.
Prior to this change, passing --systems=frog,htmlfrog would read the database
twice since the merging processing for dart:html is incompatible with dart:dom

> 
>
https://chromiumcodereview.appspot.com/10392147/diff/1/lib/dom/scripts/dartdo...
> File lib/dom/scripts/dartdomgenerator.py (right):
> 
>
https://chromiumcodereview.appspot.com/10392147/diff/1/lib/dom/scripts/dartdo...
> lib/dom/scripts/dartdomgenerator.py:17: from systembase import *
> do we care about more specific imports?
> 
>
https://chromiumcodereview.appspot.com/10392147/diff/1/lib/dom/scripts/dartdo...
> lib/dom/scripts/dartdomgenerator.py:82:
auxiliary_dir=os.path.join(current_dir,
> '..', 'src')
> nit: spaces around = here and below

[podivilov, 2012-05-21 10:30:52]

On 2012/05/18 20:49:24, sra1 wrote:
> On 2012/05/17 15:46:24, antonmuhin wrote:
> > My main concern: with this change the build will apparently become slower:
> we'll
> > reread database for each system, etc.  This greatly reduces hackability. 
Can
> we
> > do something about it in this CL?
> 
> This is my concern too.  For example, this CL has stalled my work on the
> dispatch as I have to adjust my process.
> It is my fault for not sharing my process with you earlier.
> We need to have a one-stop generate-everything, even if it re-reads the
> database.
> Prior to this change, passing --systems=frog,htmlfrog would read the database
> twice since the merging processing for dart:html is incompatible with dart:dom

Stephen,

I believe this change is a pure refactoring and doesn't affect script's
behavior. You can still generate several or all systems in one pass. If you pass
--systems=frog,htmlfrog, dartdomgenerator will create two database instances -
original and with html renames and generate both systems.
Please note that if-then-else is inside of a "for system in systems" loop.

Could you please tell what command do you use for generation and what was
changed by this patch?