[Dev] Build: generated code

Mark Jaffe markie at osafoundation.org
Tue May 18 10:14:59 PDT 2004


After considering this issue from several viewpoints, it seems to me 
that this really does belong in the repository portion of the tree, and 
we should have (and it will be documented) the requirement that any 
portion of the "chandler" tree remain "non-compiled". This obligates 
the maintainer of this portion of the code to be responsible for 
generating the resulting *.py files, with full disclosure of the method 
of regenerating from the source *.g (which should also be checked in!)

markie
On May 18, 2004, at 9:55 AM, John Anderson wrote:

> I think there is a benefit of having all the "derived" files built on 
> the same machine, automatically and continuously -- e.g. using 
> tinderbox. Hand building derived files leads to unnecessary extra 
> grunt work is another potential source of errors.
>
> John
>
> Andi Vajda wrote:
>
>> Well, this is somewhat of a new problem. So far, all of Chandler's 
>> python code
>> can be used without any build step. Downloading and installing the 
>> binaries is
>> all that is required.
>>
>> You're now introducing python code into the Chandler part of the 
>> system that
>> is auto-generated. You have two solutions:
>>
>>  - check-in the generated code along with the rest of the query 
>> system code
>>    you're adding to the repository system (having comments at the 
>> beginning
>>    of the .g file about how to re-generate the .py file are welcome).
>> or
>>  - create a new system in 'internal' that takes care of this 
>> auto-generation
>>    step. This system would bedownloaded and installed like all others
>>    during 'make install' in 'chandler'. This part of the query system 
>> would
>>    then not be part of the repository tree anymore.
>>    Note that creating this new system in internal would likely require
>>    another system being added to 'external' for Yapps.
>>
>> It seems that the first solution is a little simpler and the second 
>> one feels
>> like overkill. Java Lucene is also built that way: the auto-generated 
>> query
>> parser .java source file is checked-in and shipped with the system 
>> sources,
>> making the actual parser generator a requirement only for those who 
>> need to
>> change the query parser itself.
>>
>> Andi..
>>
>> On Mon, 17 May 2004, Ted Leung wrote:
>>
>>
>>> Hi,
>>>
>>> I'm working on a parser for the query language, and I'm using Yapps,
>>> which is a free, pure Python parser generator.  I'm trying to figure
>>> out how to integrate this in the build.  Yapps takes a grammar file 
>>> and
>>> produces a python source file that implements the parser.  So what 
>>> I'd
>>> really like to have happen is for Yapps to get invoked only when the
>>> grammar file is newer than the parser.  This probably means checking
>>> Yapps into the build somewhere and hacking a makefile(?) in order to
>>> get it to run.  Also, there's a single library support file that 
>>> needs
>>> to be included.
>>>
>>> To be more concrete, the file
>>>
>>> chandler/repository/query/parser/query.g
>>>
>>> is used to produce the file
>>>
>>> chandler/repository/query/parser/query.py
>>>
>>> and (today) relies on chandler/repository/query/yappsrt.py
>>>
>>> I've got a few days yet before I'm ready to check in, but I wanted to
>>> get this started so that the planets will align when I am ready.
>>>
>>> ----
>>> Ted Leung                 Open Source Applications Foundation (OSAF)
>>> PGP Fingerprint: 1003 7870 251F FA71 A59A  CEE3 BEBA 2B87 F5FC 4B42
>>>
>>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>>
>>> Open Source Applications Foundation "Dev" mailing list
>>> http://lists.osafoundation.org/mailman/listinfo/dev
>>>
>>>
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation "Dev" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/dev
>>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/dev
>
========================================================
Mark Jaffe                                  | (415) 946-3028 (work)
Release Engineer                    | (408) 807-2093 (cell)
OSAF                                           | (415) 946-3001 (FAX)
markie at osafoundation.org    | http://www.osafoundation.org/
PGP Fingerprint: 3435 EB88 6424 F5DF F2CA EF16 2DBF DFEF 143C 1ADE




More information about the Dev mailing list