ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "didge" <di...@san.rr.com>
Subject RE: preprocessing java source
Date Mon, 09 Sep 2002 04:55:31 GMT
Curt,

I think that a distinct preprocessing task does make sense, and one that
could process any files, not just the .java files <ppjavac> is limited to
(because it is based on <javac>).  In addition, I would implement it in a
similar pattern as the implementation of Javac (with its adapters to support
alternative compiler implementations) so that you could conceivably use
alternative preprocessors.

Incidentally, I chose Velocity because I needed a cross platform
preprocessor that was cheap and easy to integrate with my build process.  In
addition, I wanted to leverage my ant project's properties at compile time,
which no traditional preprocessor would easily be able to do.

> 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.

Ah, yes, you probably could use a merge utility to get a dump of what
changes were made to preprocessed files and put them into the
conditionalized source subject.  This is all subject to the complexity of
the changes and the source, of course.

didge

-----Original Message-----
From: Curt Arnold [mailto:carnold@houston.rr.com]
Sent: Sunday, September 08, 2002 3:57 PM
To: didge@atac.net
Cc: ant-dev@jakarta.apache.org
Subject: Re: preprocessing java source


> There isn't any real disadvantage to using the <ppjavac> task to
preprocess
> as a distinct task before <javac>.  But, just as the C preprocessor is
> automatically called for you, I wanted the <ppjavac> 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:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>



--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message