harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [classlib] Preprocessor
Date Tue, 31 Oct 2006 10:50:12 GMT


Fedotov, Alexei A wrote:
> Geir,
> 
> I tried this preprocessor staff for Java in my previous life. From my
> experience the maintenance effort is higher for this solution than for
> Source Control.

We use SVN.  How do you propose to do it cleanly in SVN?

> 
> 1. I faced first time how slow regular expressions on Java could be.
> 2. Perl worked fine but no one around me could understand my
> pre-processing scripts and maintain them.
> 3. The girl from Ireland beat my clever scripts with Sun's TeamWare and
> text editor.
> 
> +1 for Source Control
> 
> With best regards,
> Alexei Fedotov,
> Intel Java & XML Engineering
> 
>> -----Original Message-----
>> From: Geir Magnusson Jr. [mailto:geir@pobox.com]
>> Sent: Tuesday, October 31, 2006 12:28 PM
>> To: harmony-dev@incubator.apache.org
>> Subject: Re: [classlib] Preprocessor
>>
>>
>>
>> Tim Ellison wrote:
>>> Mikhail Fursov wrote:
>>>> What are the reasons to exclude the most standard solution here:
>> branching.
>>>> Do you think we need a lot of them?
>>> I don't think we are excluding any option for maintaining similar
> code
>>> streams (5.0 & 6.0, SE & ME, etc.) it's just a discussion at the
> moment.
>>> Similarly, I'm not advocating the use of aspects for maintaining
>>> different code streams; but rather I was saying that IDE support is
>>> likely going to be a requirement for any technology (apt,
> preprocessor,
>>> post-processing, aspects, ...) that we choose to solve the problem.
>>>
>>> I'm sure we wouldn't even want simple branching without a decent
> merge
>>> tool to keep things in sync.
>> Yes - that's what I'm scared of.   A branch solution sounds like it
>> leads to much misery and woe, because i think all the factors that make
>> this such an interesting problem for which a pre-processor is a valid
>> solution this implies the requirement of some kind of conditional merge
>>
>>> I agree with Geir that we should endeavour to choose a technology
> that
>>> has broad tooling support.
>>>
>>> Regards,
>>> Tim
>>>
> 

Mime
View raw message