Re: Turn off dependency checking?

[Jeff Waugh <jdub perkypants org>]

<quote who="Idan Gazit">

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

Number comments for reference strewn within. :-) I'm sure Nick will have a
few too...

> * 1 Central list of dependencies at the root of the garnome dir (this 
> will also be easier to maintain as time goes on)

1) Perhaps, but it pulls the information out of the garballs (close
approximations of packages), which is where it is most useful. If you have a
central list of dependencies, there's almost no point to the GNU make
architecture, so you'd want to move to something closer to jhbuild (which I
strongly recommend if you want to build GNOME CVS).

> * 1 small C app that (when given a target) produces a list of dependencies

2) Keeping GAR as a GNU make only system is pretty important. Note that make
is a highly evolved dependency resolver, so writing domain-specific stuff in
C just de-generalises the system and makes it less hackable. There are lots
of good reasons to futz with GAR dependencies.

> * perhaps a centralized sort of cookie listing progress, completed 
> builds (this can also serve as a centralized kind of log)

3) This is what needs to happen for GAR to move closer to 'packaging system'
from 'build tool'. However, GAR is really designed first and foremost as a
build tool, so it's not hugely important to us at the moment.

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

See point 1. Affects ports/packaging look'n'feel.

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

See point 2. Removes flexibility/generalisation from make architecture.

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

In upstream GAR, you can do this. I haven't folded upstream back into
GARNOME for a long time, since some fairly major structural changes. I will
at some stage, 'cos it's rockin' now (if a bit bigger and more complex).

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

Well, GARNOME is designed to be a distribution, rather than a fast-n-hard
updating service for the impatient and needy. :-) Thus, I'm not really
interested in improving this side of things.

(I am, however, improved in its ability to upgrade, which point 3 addresses
to a certain extent.)

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

Dude, whilst it's all ABI ccompatible, why would you care? :-)

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

(See upstream GAR. You can do all of this in make, in fact, make is *the*
way to do it.)

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

Not too much, because you went to the effort to write it in C of all things.
Nick wasn't laughing too hard when someone posted a python solution to the
GAR lists either. But he added it with very little trouble to GAR straight
away, because it's all 100% GNU make.

:-)

Thanks,

- Jeff

-- 
     "On Tuesday I saw Crouching Tiger, Hidden Dragon with Zack and two     
             ladies whom I presume are gracious." - Seth Schoen