Re: Begs, for easier source install over binary RPMS.
- From: Havoc Pennington <rhpennin midway uchicago edu>
- To: Michael Meeks <michael imaginator com>
- cc: tack dok org, "Jason S. Moore" <jsmoore brain uccs edu>, gnome-list gnome org
- Subject: Re: Begs, for easier source install over binary RPMS.
- Date: Sun, 25 Oct 1998 10:06:36 -0600 (CST)
On Sun, 25 Oct 1998, Michael Meeks wrote:
>
> I imagine that the core developers that have always worked from
> source havn't come up against the kind of wierd errors you get from the
> innumerable conflicts that occur. I invite any sceptic to get a clean
> machine, install RedHat 5.1 ( with Gnome ), and then try and compile the
> latest source following the 'Building GNOME From tar sources'
>
This won't work because it's a stupid thing to do. If you want Gnome, you
should install the packages *or* compile it yourself. Why do both?
Uninstall the packages if you want to do your own compile.
If you don't know this, you have no business compiling anything anyway.
Wait for the RPMs.
It would be a lot of effort to have configure try to check for this, and
the check would never be perfect. It would thus break things in some
cases. For example, I often have an old Gnome lying around that I want to
overwrite. I do not want configure to refuse to do so. Or I may want to
build a new Gnome on machine A, to install on machine B, but machine A has
Gnome already... there is no reason configure should refuse to do this.
Read my earlier helpful message explaining how to compile Gnome in a safe
location apart from your packages. I guess you need to add to those
instructions: uninstall any Gnome rpm's or .deb's, and uninstall the
-devel packages for Gtk 1.0.
> Well, perhaps I am doing something completely stupid, but I urge
> those that think this is a non-problem just to try ( and no cheating with
> ACLOCAL_FLAGS / funny --prefixes etc. =).
>
That's not cheating, that's how it works. ACLOCAL_FLAGS tells aclocal what
nonstandard locations to look for macros in. They are *nonstandard*, so we
can't predict where they are. We could scan the disk for .m4 files, but on
both of my systems that would fail, for different reasons (there are .m4
files that should not be used).
--prefix tells configure what directory you want to install to. It
defaults to /usr/local I think, which is reasonable. It can't read your
mind and know which to pick.
> It seems that autoconf is designed to make configuration simple,
> slick, parameterless and will create the correct configure file for your
> system state ?
>
It does do this, when it is reasonable to do so. However, it can't read
your mind and it assumes you know what you are doing. That's why you can
install something twice (there are many valid reasons to want to do this).
It can't know what prefix you want to install in unless you tell it. It
can't know what weirdo place you've installed .m4 files unless you tell
it.
Note that the *maintainers* are supposed to run aclocal/automake/autoconf,
so the idea is that the user only has to run ./configure with the
prefix of their choice. That is pretty easy, and is true of the tarballs.
To use CVS, you need the developers' tools and a little more know-how.
> What is my point ? well things are less easy than it may appear to
> those that have, from the start, used source for everything. Please try
> installing some binary RPMS right now... why not grab an old version of
> GTK and force, allfiles install it ? then try and build imlib using
> autoconf.
>
We are well aware that if you force package installations, install Gnome
twice, etc. stuff will not work. It's just that there's nothing we can
really do about it without breaking the development environment. I need to
overwrite an already-installed Gnome on a daily basis.
End users are supposed to use the packages, or at least the tarballs. CVS
snapshots are As Is. We want them to be easy to build for any potential
developers, but they are not idiot proof and you do have to learn how to
use them. They are also just plain broken once in a while. That said,
everyone is happy to help you with any problems, and we are trying to do
so. We are also taking patches to improve the build, as long as the
standard configure stuff still works, since we need that to do
development.
Havoc
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]