ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse Tilly <JTi...@hoteltools.com>
Subject RE: Javac
Date Sun, 22 Oct 2000 03:21:39 GMT
 Diane,

We had the same issue back in 1997.  At IBM, we developed network tools that
had to work in either 1.1 JVMs or 1.0 JVMs.  Here, the difference between
1.1 and 1.2 was more drastic, but the solution worked.  We forked the
project in change management into 1.0, 1.1 and common.  the 1.0 branch would
duplicate 1.1 for 1.0 specific stuff.  This required exquisite design on our
part, but allowed us the ability to cut the tree off when mgmt deemed a 1.0
version no longer necessary.  It also put us in a position to add a swing
version later on. Project build order was never important, only runtime
order.  As a suggestion, this may help in your case...although I know very
little about it, so I could be completely offbase.  Anyway, hope it helps.

Jesse

-----Original Message-----
From: Diane Holt
To: ant-user@jakarta.apache.org; AGerhard@E-SyncNet.Com
Sent: 10/20/00 9:47 PM
Subject: RE: Javac

Hi Alan,

Thanks for the suggestion (and for the code, which I'm always interested
in seeing, since I don't really know Java yet) -- but I probably should
have mentioned that the reason I even have build-order issues is because
I
can't just hand off all the source to the compiler at once -- and the
reason I can't do that is because I have files that need to include 1.2
classes and other files that -can't- use 1.2 classes. What it actually
amounts to is more of a classpath-ordering issue (sort of like the old
link-library issues you could run into with C). I can't have a classpath
that includes both 1.1.8 and 1.2, because if I put the 1.1.8 classes
first, then the files that require 1.2 will pick those up instead (and
fail), and I can't put the 1.2 classes first, because then the source
that
requires 1.1.8 will pick up the 1.2 classes (and be wrong and/or fail).

So I can't just have a generic <javac> task, regardless of whether I
feed
it small sets of source-files or all the source-files, because I need
the
classpath to be different, depending on which source is being handed off
to the compiler. I do eventually get past those special-needs files and
use an includes file (which just has subdirs listed with **) and an
excludes file that goes along with that (since I have source in my
source
tree that shouldn't be included in the build).

All in all, it's kind of a mess -- but what're you gonna do? :)

Diane

--- Alan Gerhard <AGerhard@E-SyncNet.Com> wrote:
> Diane -
> 
> Maybe by using the 	includesfile="${cListFile}"
> attribute might help out a bit.
> 
> Of course you would have to generate cListFile, but that's relatively
> straight forward, even if you have complex conditions.
> 
> Follows is how we implemented a class list
> 
> [...
> 	<target name="tools" depends="init">
> 		<javac srcdir="${build}" destdir="${build}"
includes="mkClist.java,
> mkDlist.java" />
> 	</target>
> 
> 	<target name="mkLists" depends="tools">
> 		<java classname="mkClist" args="${source}  ${cListFile}"
/>
> 		<java classname="mkDlist" args="${classes} ${dListFile}"
/>
> 	</target>
> 		
> 	<target name="make" depends="mkLists">
> 		<javac srcdir="${source}" 
> 				destdir="${classes}" 
> 				includesfile="${cListFile}"
> 				debug="${debugValue}"/>
> 	</target>
> ...]
> The code for mkClist -
> import java.util.*;
> import java.io.*;
> public class mkClist {
> 
> 	public static void main(String[] args) throws Exception	{
> 
> 		try {
> 
> 			DataOutputStream dOS  = new DataOutputStream(
new
> FileOutputStream(args[1]));
> 			mkClassList(args[0],dOS);
> 			dOS.close();
> 
> 		} catch (Exception exp) {
> 				exp.printStackTrace();
> 
> 				System.out.println("\nmkClist takes two
parameters, the directory
> and the file name to which output is written to.");
> 				System.out.println("Example -> java
Source ..\\Source
> cList.txt\n\n");
> 		}
> 
> 
> 	}
> 
> 	private static void mkClassList(String name, DataOutputStream
pdOS
> )throws Exception {
> 
> 		File dir = new File(name);
> 		String fileSeperator = dir.pathSeparator;
> 		String[] list = dir.list();
> 
> 		for (int i = 0; i < list.length;i++)	{
> 
> 			File file = new File(dir,list[i]);
> 
> 			if (file.isDirectory())	{
> 				mkClassList(name + dir.separator +
list[i], pdOS);
> 
> 			}	else {
> 				if
(list[i].toLowerCase().endsWith(".java") )	{
> 					pdOS.writeBytes(name +
dir.separator + list[i] + "\r\n");
> 				}
> 			}
> 
> 		}
> 
> 	}
> 
> };
> *****************************
> 
> alan
> 
> 
> 
> -----Original Message-----
> From: Diane Holt [mailto:holtdl@yahoo.com]
> Sent: Friday, October 20, 2000 3:10 PM
> To: ant-user@jakarta.apache.org
> Subject: Re: Javac
> 
> 
> I also have build-order issues (it makes me feel a whole lot better to
> finally find someone else who does :)  I have separate <javac> tasks,
> and
> in the order the compiles should happen. One thing you have that's not
> right is specifying the full package-path in "srcdir" -- <javac>
doesn't
> like that. You need to specify "srcdir" as the path leading up to
where
> the COM/pkg/etc. starts, then include the COM/pkg/etc. as part of the
> filenames of the files you want this <javac> task to compile:
> 
>   srcdir="${srcDir}
> ...
>   <include name="com/hcl/dal/Whatever.java"/>
> etc.
> 
> But note -- there's no way I know of to prevent side-effect compiles
> (eg.,
> I have a <javac> task that lists 2 source-files, but it ends up with
750
> classfiles having been compiled, since Java compilers go build what
they
> need when they need it).
> 
> Diane
> 
> --- Dan MacKay <dan.mackay@KINGSTON.HUMMINGBIRD.COM> wrote:
> > Hi all,
> > 
> > Is it possible to have javac not compile a whole tree. I have to
> control
> > the
> > the order of compilation. My directory structure is as follows:
> > 
> > root directory:
> >                file1.java
> >                file2.java
> > 
> >                sub_dir1:
> >                         many files *.java
> > 
> >                sub_dir2:
> >                         many files *.java
> > 
> >                sub_dir3:
> >                         many files *.java
> > 
> > I have to compile and stage these files at different points through
> the
> > build process. I have to start at the root and compile the two files
> > there
> > to the exclusion of the rest of the files in the resident
> > sub-directories.
> > My initial niave attempt was as follows:
> > 
> >   <target name="compile"  depends="getSource" >
> >   <!-- Build the root -->
> >     <echo message="Building the root"/>
> >     <javac optimize="${optimize}"
> >            srcdir="${srcDir}\com\hcl\dal\"
> >            destdir="${outDir}"
> >            classpath="${cdkDir}\lib/nova.jar;${outDir}"
> >            debug="${debug}"/>
> >   <!target>
> > 
> > This blithly motors along and compiles the whole shebang,
> > sub-directories
> > included and eventually fails in the sub_dir1 build when it cannot
> find
> > dependancies for resources have not been found because they have not
> > been
> > staged yet. Could someone give me an example of the includes/exclude
> > directives that would be necessary to ensure that only file1.java
and
> > file2.java are compiled?
> > 
> > Thanks
> > 
> > Dan
> > 
> 
> 
> =====
> (holtdl@yahoo.com)
> 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Messenger - Talk while you surf!  It's FREE.
> http://im.yahoo.com/


=====
(holtdl@yahoo.com)



__________________________________________________
Do You Yahoo!?
Yahoo! Messenger - Talk while you surf!  It's FREE.
http://im.yahoo.com/

Mime
View raw message