Re: Turn off dependency checking?


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 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....


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