Re: gar.lib.mk still wrong



On Sat, 03 Mar 2007 18:09:43 +0100, guenther wrote:

snip....

> 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.
>
Yes, the task is more complex serving more masters.
>
snip...

>
> 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.
>
Well, here's how I do it. NOT ALL gnome apps require the latest. If there is
a version deficiency, configure bombs out and the out-of-date library needs
to be updated. For example, garnome ships expat-2 whereas I happily get away
with expat-1.95.8 and all compiles fine. In other cases, packages need
updating.

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

Oh don't misunderstand me. I am happy now :) garnome is a terriic platform
and build system. I just try and save some time since other applications
benefit from many common libraries and applications (e.g. dbus, hal, etc).

Trying to figure out library versions, especially for packages that don't
use pkgconfig is very hard. Not worth the effort if you ask me.

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

I think the best approach would be to have a user config file only for use
by those who WANT to bypass files or libraries. I don't think trying to make
garnome too smart is worthwhile.

snip...

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

Well, at least it was not a little bit broken. Those kinds of bugs are
impossible to squash. Really borked things are easier :)

snip...

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

Being in the US, we tend to overlook these things. That is wrong!

>   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; }}}
>

I finally compiled your sig. Very cute :)

--
Peter




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