From ant-dev-return-37636-qmlist-jakarta-archive-ant-dev=jakarta.apache.org@jakarta.apache.org Sun Sep 08 22:57:00 2002
Return-Path:
Delivered-To: apmail-jakarta-ant-dev-archive@apache.org
Received: (qmail 10584 invoked from network); 8 Sep 2002 22:57:00 -0000
Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131)
by daedalus.apache.org with SMTP; 8 Sep 2002 22:57:00 -0000
Received: (qmail 23388 invoked by uid 97); 8 Sep 2002 22:57:37 -0000
Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org
Received: (qmail 23372 invoked by uid 97); 8 Sep 2002 22:57:37 -0000
Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe:
List-Subscribe:
List-Help:
List-Post:
List-Id: "Ant Developers List"
Reply-To: "Ant Developers List"
Delivered-To: mailing list ant-dev@jakarta.apache.org
Received: (qmail 23360 invoked by uid 98); 8 Sep 2002 22:57:36 -0000
X-Antivirus: nagoya (v4218 created Aug 14 2002)
Message-ID: <003701c2578b$04025e90$a800a8c0@CurtMicron>
From: "Curt Arnold"
To:
Cc:
References:
Subject: Re: preprocessing java source
Date: Sun, 8 Sep 2002 17:56:49 -0500
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
> There isn't any real disadvantage to using the task to
preprocess
> as a distinct task before . But, just as the C preprocessor is
> automatically called for you, I wanted the to be integrated into
> the task for compilation, a sort of drop in replacement for the javac
task.
> However, an additional option could be added that would allow compilation
to
> be optional. Then you could preprocess and compile in two steps, as
> desired. You would only have to coordinate the location of the
preprocessed
> files between the two tasks.
My initial feeling is that it would be cleaner as a distinct task. An
alternative would be to enhance the cc task to emit preprocessed files using
whatever C++ preprocessor is available and then use the javac class.
>
> I'm not exactly clear on the development process you're suggesting in your
> second comment, but the concern of checking in preprocessed files is that
> one you check in a preprocessed file, all the information that yielded the
> file, e.g. VTL directives, cpp #define, etc., are lost and you can't go
back
> (except maybe manually and at great effort).
If the changes were moderately localized (as typical in bug fixing and
feature enhancement), you could make modifications to the preprocessed file
and use a merge utility to create a new conditionalized source from the
unaltered preprocessed file and the unaltered conditionalized source. You'd
use the merge utility as if one developer added all the preprocessor
directives to the unaltered preprocessed file and another developer added
the bug fixes. This would not work if you made major structural
modifications to the preprocessed file.
--
To unsubscribe, e-mail:
For additional commands, e-mail: