Re: Turn off dependency checking?

[Idan Gazit <id panix com>]

Hey,

So I'm no great shakes at C, and I am definitely not too knowledgable 
about the build process, but what about the following:


* 1 Central list of dependencies at the root of the garnome dir (this 
will also be easier to maintain as time goes on)
* 1 small C app that (when given a target) produces a list of dependencies
* perhaps a centralized sort of cookie listing progress, completed 
builds (this can also serve as a centralized kind of log)


I don't know much about makefiles (just a beginning developer), but 
perhaps it can be rigged to somehow call the small C app to determine 
dependencies and then consult with the cookie file to see if they're 
satisfied (perhaps the C app can do this for you also)

Bonuses with this approach:


* Easier to maintain deps.
* You pay the dep resolution "price" at the door, when you compile the 
little C app once. Afterwards it resolves deps in about a nanosecond.

* With very little effort, users can also use the app to query the 
dependency tree when they feel like upgrading a single part of the tree.

For instance: several new tarballs have appeared on ftp.gnome.org. I 
have a burning desire to upgrade to gedit-x.x.x because it can tell me 
who shot JFK. The next version of garnome is not yet released, and I 
don't feel like editing the makefiles and replacing checksums in the 
garnome/gnome/gedit dir to fool it into doing the work for me; I know 
that it's just a ./configure; make; make install kind of affair anyways. 
The only way for me now to know if the libraries that gedit-x.x.x 
require are in place is for me to manually do a recursive check of 
everything that gedit has in its LIBDEPS. With the C app & central 
repository I can just go "depfinder gedit" and get a nice clean list.

Fiction? Nay. Well, I wrote this app, but I must have done something 
wrong because it segfaults on a malloc (no, I haven't double-freed 
something) when it's dealing with _really really_ long lists of 
dependencies. For normal ones it works just fine and produces output like:

id:~/src$ ./depfinder gedit
Dependency build order for gedit:
0: libart_lgpl
1: pkgconfig
2: gtk-doc
3: glib
4: atk
5: freetype
6: pango
7: gtk+
8: libxml2
9: libglade
10: libgnomecanvas
11: linc
12: libIDL
13: ORBit2
14: bonobo-activation
15: libbonobo
16: GConf
17: gnome-mime-data
18: gnome-vfs
19: audiofile
20: esound
21: libxslt
22: libgnome
23: libbonoboui
24: libgnomeui
25: libgnomeprint
26: libgnomeprintui
**: gedit


So, when everybody is done laughing at the guy who doesns't know C, let 
me know what you think. If it's worth it I'll spend the time debugging 
it carefully to eradicate this bug. Building the dependency file is also 
really really easy and can be automated with a 7 line shell script (I 
did it by hand) -- grep -r "LIBDEPS" > depfile, followed by a bit of 
sed'ing to pare it down the the form:

target: dep1 dep2 dep3

The app is also smart enough to not add previously built dependencies to 
the list, e.g. pkg1 and pkg2 both require pkg0, and say so in their 
LIBDEPS. Pkg0 will only show up once in the list, despite being looked 
for twice.

I hope y'all aren't laughing too much....


Idan