Re: Conditional dependencies

Lars Ivar Igesund wrote:

> It struck me once that the dependencies found by ddepcheck wasn't 
> necessarily correct at all times. This is due to the possibility to 
> conditionally include/exclude parts of the source code using compiler 
> switches. Correct dependencies for any given compilation run would 
> therefore need ddepcheck to also look at these switches. I have 
> implemented this (looks hairy at the moment) on my local copy of 
> ddepcheck, but there is another problem that might, well, be a problem.
> 
> If the switches are changed, changing the dependencies, but not the 
> source code itself, can this be handled by A-A-P? I suppose dependency 
> checking of C/C++ where includes are conditionally included/excluded by 
> define might have the same problem.

There are two ways to do the dependency checking:
1. Without looking at conditionals.  Thus more files are found than what
   is actually used.
2. Taking conditionals into account.  Then the list of files is
   accurate, but may change when the circumstances change.

In the first case there are no tricks, no need to check the dependencies
again when you change conditionals.

In the second case, the build signature should include the
circumstances.  For C these are the preprocessor symbols.  This should
already happen, since Aap uses a signature for the build commands.

When an included file changes that may define different symbols, it's
more complicated.  Example:

	file.c:
		#include "defines.h"
		#include "includes.h"
	
	defines.h:
		#define ONE
		// #define TWO
	
	includes.h:
		#ifdef ONE
		# include "one.h"
		#endif
		#ifdef TWO
		# include "two.h"
		#endif

Depending on whether ONE and/or TWO are defined in defines.h, the
dependency of includes.h changes.  But you can't see that when just
looking at includes.h.

As it is when using gcc it will work correctly.  It just verified that.
You always edit a file that's already one of the dependencies, thus Aap
will run the dependency checker.

Perhaps there are situations where a change isn't noticed?

-- 
For humans, honesty is a matter of degree.  Engineers are always honest in
matters of technology and human relationships.  That's why it's a good idea
to keep engineers away from customers, romantic interests, and other people
who can't handle the truth.
				(Scott Adams - The Dilbert principle)

 /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net   \\\
///        Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
 \\\  Buy at Amazon and help AIDS victims -- http://ICCF.nl/click1.html ///


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com