javac (command-line) can easily be forced to be privy to whatever you so wish it to be.
IIRC the default sourcepath is your working directory. javac will use that to look-up any source files it needs for any implicit compilation it deems necessary. If the sourcepath is suppressed by issuing 'sourcepath ""', it forces javac to ONLY be aware of the source files you tell it about (including for any implicit compiliations that occur as a result of dependencies). It would be nice to be able to achieve this using specific filesets for each specified source directory in the <javac> task. FYI I am having to do this because of some auto code generation. At the beginning of development, you generate a skeleton of source files. One of these is an empty implmentation class, which you then take away and, well, implement. At build time, I am generating the skeleton again (to ensure non-implementation Java files are correct), but then combining it with the real implementation class (this is the duplicated class). Not dangerous in my book. Regards, Joe -----Original Message----- From: Steve Loughran [mailto:[EMAIL PROTECTED] Sent: 26 April 2006 12:49 To: Ant Users List Subject: Re: Javac: multiple source roots & filesets Wildish, Joe STASCO-OTO/72 wrote: > java root_a/One.java root_b/Two.java root_b/Three.java > > javac handles this OK (ie. it is not privy to root_a/Two.java, so does not > attempt to compile it). Like I warned, this is not always the case java.exe will pull in any java files it sees fit to compile something, provided they are laid out in a proper hierarchy. This is why you dont need to specify the exact order to compile files. As sun say in the javac.html page "javac can silently compile source files not mentioned on the command line." That's why using the command line to selectively filter stuff is a bad thing. Even at the terminal prompt, you can get burned. >Is the javac task not simply mimicking this behaviour? In which case, I should be able to emulate this within a target...? > javac does other things like dependency checking, wrapping around other compilers and the like. you can always use <exec> to call javac if you want. Personally, I think what you are trying to do is dangerous. It looks like you're trying to have per-platform/per-release customisation by producing different .class files for different systems. There are better ways to do this that are cleaner and more manageable -use the SCM system and branch -use an interface/implementation pattern and compile different implementations -tease the file that changes out into its own location (or even separate JAR), so you just include what you want, instead of trying to exclude things. Now, if <src> doesnt let you support multiple fileset sources then that may be a defect we need to fix, but I dont think your use case is something to encourage. Sorry. -steve --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
