Re: dependency scanner

Lew wrote:
> Aryeh M. Friedman wrote:
>> Lew wrote:
>>> Aryeh M. Friedman wrote:
>>>> In short I am *NOT IMPRESSED* with Java's ability to manage large 
>>>> projects,   In a way this is the same issue recursive make has 
>>>> http://aegis.sourceforge.net/auug97.pdf
>>>
>>> Funny, I don't remember anyone claiming that Java is a 
>>> project-management system.  I thought it was a programming language.  
>>> Do you blame C for not having the features of make, I wonder?
>>
>> C does at least has a trivial way to find depends (#include)
> 
> Huh?  What does #include have to do with managing object file
dependencies?


As with any type of build procedure there are implicit and explicit 
depends that make/cook/whatever needs to handle...  Explicit ones are 
the ones you are thinking of when you are thinking that foo.c depends on 
ack.c because it uses bar() from ack.c... *BUT* since ANSI (and almost 
all compilors accept ANSI by default now) requires a prototype (even if 
it returns an int or void) this means I need to define the prototype for 
bar() somewhere and more often then not you do that in ack.h... now in 
foo.c I have:

	#include "ack.h"

Assuming that I use the same name for the .h and .c it goes to I only 
need to scan for #include's in foo.c and do a batch processed search and 
replace (say with sed in unix) and replace all .h with .c (or actually 
..o for techinical reasons)... this now gives me a list of all my 
implicit depends (due to the need to prototype about 95% of the total 
for a typical project)... All I need to do in the 
makefile/cookbook/whatever is add a rule like this (cook has nicer 
syntax then make so I will use it):

	%0%.o: %0%.c			
	/*in reality I would also add a call to the dep scanner above*/
	{
		gcc [command line opts] -c %0%.c -o [target];
	}

You should be asking now how to handle explicit depends... thats when 
you actually hard/softcode it into the makefile/cookbook/whatever with 
something like:

	bin/foo: lib/liback.a
	{
		gcc -Llib foo.c -o [target];
	}

	lib/liback.a: lib/ack.o lib/fred.o ....
	{
              ar rv [target] ack.o fred.o ...
	}

Almost all these can be soft coded by various tricks with a good depend 
scanner for example to get the "ack.o fred.o ..." list I would just say 
every .c in lib/ needs to become a .o.


Now cook does something really smart at this point compared to make.   I 
  creates the entire DAG *BEFORE* attempting to build any target thus 
allows you to avoid all the issues in RMCF.

Due to this premade DAG approach I can use the same cookbook to build 
and package multiple packages (using the java term) *BUT* only when 
something in them or a package they depend on changes.

The reason for the orginal question is I do not want to have to use 
nothing but explicit depends and if I am writting this for public 
release the person who DL's the source code will not have any .class 
files yet.

> 
> If you recompile foo.c and bar.o depends on foo.o, nothing in C is going

> to help you figure that one out, via #include or otherwise.  You need 
> make for that.
> 
> #include is a *pre*-processing step; it happens before the compilation 
> even looks at the source code.  There is no equivalent in Java.  The 
> 'im****t' directive does not include anything at all; it just helps the 
> compiler with name resolution.
>