Re: gar.lib.mk still wrong

[guenther <guenther rudersport de>]

> > However, IMHO we should default to the GARNOME built tool, if it exists,
> > and fall back to the system one otherwise. If neither one exists, just
> > freak out and stop the build. :)
> 
> Well, Joseph and I have debated this a bit off list. I contend there is no
> need to provide build tools in Garnome, He'll tell you of my hack
> experiments, or you can email me at pete at peterhyman dot com for more
> color. Personally, I see no reason for pkgconfig, libtool, intltool,
> autoconf, automake, etc. to be shipped with garnome. Most modern distros
> have perfectly acceptable versions.

Granted, some build tools in bootstrap/ could be removed. However, we do
need to provide a bunch of them, because GARNOME aims at supporting
bleeding edge distros just as well as that 2 year old system that just
runs smoothly.


> As for some of the less common libraries shipped with garnome, pcre, neon,
> libdaemon, etc., there is room for debate. I have had great success
> bypassing them and about 30 others in garnome as well.

We do need these. Believe me, we would not have added stuff like liboil
and libexif without the need to. In most cases core GNOME apps simply
bumped their requirements to versions, which have been released within
the last 6 or 12 months. Without providing them, we would limit the use
case for GARNOME to bleeding edge distros -- which is not what we want.


I know you talked to Joseph about these external dependencies before,
and I do have an idea to implement automatic, conditional build of them
(supporting explicit disabling of external deps). Which should make you
happy, once I got around to implementing this. :)

I would like to see how this works out in your case, and I definitely
will ping you for some testing. :)  If you want to discuss such issues
in a more interactive way, feel free to join us on IRC.


> Glad you were able to fix up gar.lib.mk, BTW though, the "bug" never showed
> itself when users used the garnome-supplied build tools. Only when they were
> bypassed.

Exactly. As I explained, the fixup code was so horribly broken, that it
could work in one case only -- using the GARNOME built tools.

The new code should just does what it was supposed to do in the first
place. Of course GARNOME provided tools take precedence, but they are
not required. It happily will just work, if for example libtool has not
been built by GARNOME but is available in your $PATH system wide. This
also should just do what you want. ;)

Note though, that there is a reason to default to the GARNOME provided
tool. Especially in the case of intltool, packagers usually provide it
as part of their tarball releases, frequently using an old (and
sometimes known to be broken) version. This recently was (is) an issue
with various intltool releases and being broken wrt the LINGUAS*
variables. Hence the need to default to a known-to-work version.

  guenther


-- 
char *t="\10pse\0r\0dtu\0  ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}