ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <>
Subject Re: uptodate tasks and CVS timestamps
Date Tue, 12 Feb 2002 23:51:59 GMT

----- Original Message -----
From: "Dominique Devienne" <>
To: <>
Sent: Tuesday, February 12, 2002 13:17
Subject: uptodate tasks and CVS timestamps

> Hi All,
> I have a target called "viz.release-up2date?" that uses <uptodate> to
> out whether a DLL needs recompiling (done by another target based upon the
> viz.release-up2date property being set or not). This task worked fine most
> of the time, but not all of the time (not to ANT fault, but due to CVS I'm
> afraid). Consider the following scenario:
> 1) DLL was compiled successfully, so it's up-to-date
> 2) Remove one source file of the DLL
> 3) CVS update to get that file back.
> In 3) the file now has the date at which the cvs update command was run,
> which is more recent that the DLL's date. The DLL is thus considered
> out-of-date when it's logically perfectly up-to-date compared to the
> code.
> Consider this other scenario:
> 1) New user checks out new sandbox using CVS checkout. This get him the
> bin\ directory containing the DLL in question (yes, it's committed to CVS
> since not all users have C++ compilation environment, so they need the DLL
> for running the application. It's a mixed Java / C++ project) before the
> src\ directory.
> The DLL in the repository is up-to-date compared to its source, but since
> was created in the local sandbox before its sources, it appears to be
> out-of-date!!!
> What's one to do in this situation?
> I can envision a scheme where a custom ANT task was written to compute a
> checksum (CRC32 or Adler for non-secure checksum, or more secure but
> hashes) of all the source files, somehow being able to associate that
> checksum to the target DLL in a persistent manner (how? I don't know, but
> saving it in a committed file next to the DLL???), and only when the
> checksum of the source files changes from the one recorded would the
> be considered out-of-date....
> Is this too far fetched?
> As anyone faced the same problem, and solved it?

In the ant1.5 alpha on CVS there is a simple <filesmatch> condition, which
lets you for files being equal.

The problem you have is that you dont know what the final file will be,
without rebuilding it. Nothing springs to mind as a solution there.

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message