Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Ant Rant



On Fri, Dec 03, 2004 at 09:24:18AM -0500, David Kramer wrote:
> Here's the thing I'm finding out about ant.  It doesn't do the one single most 
> primary thing a build system needs to do: Only build things that need to be 
> built.

I like ant for its portability, but it can *really* try your patience.

If I understand what you're asking, it certainly is possible... just a
bit more cumbersome than the equivalent thing in Make.

You accomplish it in two parts:

1) Set a property based on a condition

2) Call a target that contains an "if" or "unless" attribute

Here's an example of checking a .so library against its sources:

  <uptodate property="library-is-current" targetfile="mylib.so">
    <srcfiles dir="mylib/sources" includes="*.c"/>
  </uptodate>

  <antcall target="build-my-lib"/>

          .
          .
          .
          .

  <target name="build-my-lib" unless="library-is-current">
          .
          .
          .
          .


There's a fair amount of flexibility in uptodate, and other
condition-checkers available. Also a <dependset> task that can help
manage dependencies. It's not as simple as in Make, and probably not as
expressive, but it'll probably solve the problem for you.

Nathan


> There does not appear to be a way to make a build.xml file with a 
> target such that if a particular module is already built, you don't try to 
> build it again.  No way to say "this target has already been built".  No way 
> to say "this file is newer than that one, so no need to build this target". 
> No way to say "This file exists, so no need to build this target".  This is 
> crucial, because using antcall or ant targets run in a separate thread that 
> has no access to the dependency calculations already done in the calling ant run.
> 
> Debugging ant scripts also seems to be somewhat daunting, since it's not 
> composed of a list of steps to run, and many tasks are Java code.
> 
> Beyond disappointing.  Am I missing something?
> 
> My current inclination is to have a master bash script that controls the logic 
> and dependencies, then builds each individual module by running make, running 
> MSVC with the project files, or running the ant script, depending on the 
> module's source file type and platform.
> 
> I really have to pick the technology tomorrow if I'm going to get this done in 
> time.
> 
> 
> -- 
> DDDD   David Kramer        david at thekramers.net     http://thekramers.net
> DK KD  "Asking whether there is a liberal or conservative bias to the
> DKK D  mainstream media is a little like asking whether al Qaeda uses too
> DK KD  much oil in their hummus.  The problem with al Qaeda is that
> DDDD   they're trying to kill us."                           - Al Franken
> _______________________________________________
> Discuss mailing list
> Discuss at blu.org
> http://olduvai.blu.org/mailman/listinfo/discuss
> 
> 




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org