avr-libc-dev
[Top][All Lists]
Advanced

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

Re: [avr-libc-dev] Re: circ dep fix


From: Joerg Wunsch
Subject: Re: [avr-libc-dev] Re: circ dep fix
Date: Mon, 5 Aug 2002 21:31:26 +0200
User-agent: Mutt/1.2.5i

As Theodore Roth wrote:

> :) Hmm, i thought the Makefiles would respect ${DESTDIR}?
> :)
> :) env DESTDIR=/tmp ./domake install

> :) I'll see whether i can fix this.  This would allow me to install into
> :) a test hierarchy as a regular user.
> 
> There's nothing to fix. Just don't use the do* scripts.

Well, i think that's more a misfeature of automake, see the followup to
my own mail.  It places empty DESTDIR= macros in each and everey
generated Makefile.in.  I don't think using another method than the do*
scripts would change the behaviour, and in fact

./domake DESTDIR=/tmp install

did work for me (domake passes all its arguments down to the make
utility).

> I personally only
> use the reconf script, then manually run configure as such (from obj-avr
> subdir):
> 
>   $ cd obj-avr; ../configure --prefix=$HOME/local/libc-test

Hmm.  However, --prefix is something different than DESTDIR.  DESTDIR
is used to modify the entire root of the installation target.  So you
configure it as normal, e. g. with --prefix=/usr/local (the default),
compile it, but when it comes to installation, you say DESTDIR=/foo,
and it will install it all into /foo/usr/local.

In this case, it's simply useful for testing to see what would be
installed.  But there are other uses for this feature.  Sorry to
always refer to FreeBSD here :), but that's what i know best.  All
the *BSD Makefiles also honor $DESTDIR, so it's easy to instantiate
a complete operating system environment using it, e. g. for a chroot
environment.  You just say "cd /usr/src; make install DESTDIR=/chroot",
and you'll get a fresh copy of the entire system under /chroot (of
course, assuming you did a normal "cd /usr/src; make" job before).

In my case it's merely to see what will be installed without clobbering
the existing older installation of avr-libc under /usr/local (which
itself stems from a FreeBSD package installation so i wouldn't like
to temper with it unless when installing an updated package).  Of course,
i could as well create a complete new toolchain (binutils, avr-gcc,
avr-libc) under something else than /usr/local by compiling and
installing all three of them with another --prefix setting, but right
now i don't need this.  Currently i'm only testing the documentation
stuff, so it's unimportant to me whether the installed tree would be
able to work (it's certainly unable to work under /tmp/usr/local)
as long as i can verify that the installed docs are OK.

-- 
J"org Wunsch                                           Unix support engineer
address@hidden        http://www.interface-systems.de/~j/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]