Re: Why does Makefile depend on BUILT_SOURCES?

2000-03-15 Thread Tom Tromey
> ">" == OKUJI Yoshinori <[EMAIL PROTECTED]> writes: >> 2. The target `Makefile' depends on $(BUILT_SOURCES). >> The solution may be to get rid of the dependency in the item 2, >> so my question is why Makefile must depend on BUILT_SOURCES. Is >> there some good reason? Only a historical

Re: libtool /tmp security

2000-03-15 Thread Gary V. Vaughan
On Wed, Mar 15, 2000 at 03:16:16AM -0300, Alexandre Oliva wrote: > On Mar 13, 2000, "Gary V. Vaughan" <[EMAIL PROTECTED]> wrote: > > > I would still like to see {auto{conf,make},libtool} use Ralf > > Engelschall's shtool (or a variant of it) to encapsulate the > > portability issues of things lik

Why does Makefile depend on BUILT_SOURCES?

2000-03-15 Thread OKUJI Yoshinori
I'm now investigating why the latest CVS version of Automake doesn't work with GRUB nicely. I've already sent some patches to bug-automake, but I encountered another problem; "make distclean" doesn't work. After looking into it by "make -d distclean", this turned out: 1. The target `distclea

Re: libtool /tmp security

2000-03-15 Thread Earnie Boyd
--- Akim Demaille <[EMAIL PROTECTED]> wrote: > > "Earnie" == Earnie Boyd <[EMAIL PROTECTED]> writes: > > >> Let it be for speed issues, I'm in favor of /tmp via TMPDIR. This > > Earnie> You missed the point; /tmp isn't portable, it doesn't always > Earnie> exist (E.G.: MSDOS or WINDOWS). A

Re: libtool /tmp security

2000-03-15 Thread Akim Demaille
> "Earnie" == Earnie Boyd <[EMAIL PROTECTED]> writes: >> Let it be for speed issues, I'm in favor of /tmp via TMPDIR. This Earnie> You missed the point; /tmp isn't portable, it doesn't always Earnie> exist (E.G.: MSDOS or WINDOWS). At least with TMPDIR I can Earnie> set it to be whatever I

Re: libtool /tmp security

2000-03-15 Thread Alexandre Oliva
On Mar 15, 2000, Earnie Boyd <[EMAIL PROTECTED]> wrote: > Why use /tmp at all? Because those commands are run at install time, when the program/library has to be relinked for installation. In this case, we can't assume the current directory, i.e., the build tree, is writable. > Since autoconf

Re: libtool /tmp security

2000-03-15 Thread Earnie Boyd
--- Akim Demaille <[EMAIL PROTECTED]> wrote: > > "Earnie" == Earnie Boyd <[EMAIL PROTECTED]> writes: > > Earnie> --- Akim Demaille <[EMAIL PROTECTED]> wrote: -8<- > >> As for mkdir -m, it seems to me that > >> > >> (umask 700 && mkdir /tmp/foo) > > Grmph, 077. > > >> > >> is just fine. >

Re: libtool /tmp security

2000-03-15 Thread Akim Demaille
> "Earnie" == Earnie Boyd <[EMAIL PROTECTED]> writes: Earnie> --- Akim Demaille <[EMAIL PROTECTED]> wrote: -8<- >> As for mkdir -m, it seems to me that >> >> (umask 700 && mkdir /tmp/foo) Grmph, 077. >> >> is just fine. >> Earnie> -8<- Earnie> Why use /tmp at all? Since autoconf is fo

Re: libtool /tmp security

2000-03-15 Thread Earnie Boyd
--- Akim Demaille <[EMAIL PROTECTED]> wrote: -8<- > > As for mkdir -m, it seems to me that > > (umask 700 && mkdir /tmp/foo) > > is just fine. > -8<- Why use /tmp at all? Since autoconf is for portibility you can't really assume that /tmp exists. Why not simply create a temporary directory

Re: libtool /tmp security

2000-03-15 Thread Akim Demaille
| On Mar 13, 2000, "Gary V. Vaughan" <[EMAIL PROTECTED]> wrote: | > I would still like to see {auto{conf,make},libtool} use Ralf | > Engelschall's shtool (or a variant of it) to encapsulate the | > portability issues of things like mkdir -p and mkdir -m 700 into a | > single script rather than sc