Re: Automake security problem

2000-03-01 Thread Sascha Demetrio
Alexandre Oliva wrote: > On Mar 1, 2000, Jim Meyering <[EMAIL PROTECTED]> wrote: > > > Don't use `ln' (which was just a space optimization anyway) > > A worthwhile optimization, IMO. [...] Maybe using `ln' in `make dist' should be optional? The links in the dist directory can easily becom

RE: REPLACE_GNU_GETOPT

2000-03-01 Thread Tom Tromey
Hal> That would be something I would install on my development system? Hal> Would I need to put it somewhere special so it doesn't go away if Hal> I upgrade automake? I would really rather do it the "proper" way Hal> if true. Or is get a copy the "proper" way? Still trying to get Hal> my br

RE: REPLACE_GNU_GETOPT

2000-03-01 Thread Duston, Hal
Tom Tromey [[EMAIL PROTECTED]] wrote > > "Hal" == Duston, Hal <[EMAIL PROTECTED]> writes: > ---snip--- Me asking about AC_REPLACE_GNU_GETOPT ---snip--- > This stuff you found is sort of a relic from the old days, when > automake was more or less used only by the Gnits people. > AC_REPLACE_G

Re: REPLACE_GNU_GETOPT

2000-03-01 Thread Tom Tromey
> "Hal" == Duston, Hal <[EMAIL PROTECTED]> writes: Hal> I am setting my package up with automake/autoconf, and want to Hal> provide gnu getopt if it is not available. I noticed Hal> AC_REPLACE_GNU_GETOPT in the info file, but it doesn't seem to be Hal> completely implemented. It is in autom

REPLACE_GNU_GETOPT

2000-03-01 Thread Duston, Hal
Hello, I am setting my package up with automake/autoconf, and want to provide gnu getopt if it is not available. I noticed AC_REPLACE_GNU_GETOPT in the info file, but it doesn't seem to be completely implemented. It is in automake, and the info file, but nowhere else I could see. Is this

Re: Automake security problem

2000-03-01 Thread Tom Tromey
Jim> Here's an untested patch. I'll look at this soon. Jim> BTW, Tom, what about that last patch I sent in (testing for close Jim> failure)? Yeah :-( I haven't had much automake hacking time for a while (again). I guess I'd like to get more people checkin rights to make up for my failings. Ji

Re: AC_PROG_LIBTOOL vs. AM_PROG_LIBTOOL in automake-1.4.a

2000-03-01 Thread mdejonge
Alexandre Oliva wrote: > > On Mar 1, 2000, [EMAIL PROTECTED] wrote: > > > Shouldn't automake issue a warning like: > >automake: configure.in: installing `./ltconf' > > as it does for other missing files? > > No, because ltconfig is not part of automake, it's part of libtool. > You should r

Re: AC_PROG_LIBTOOL vs. AM_PROG_LIBTOOL in automake-1.4.a

2000-03-01 Thread Alexandre Oliva
On Mar 1, 2000, [EMAIL PROTECTED] wrote: > Shouldn't automake issue a warning like: >automake: configure.in: installing `./ltconf' > as it does for other missing files? No, because ltconfig is not part of automake, it's part of libtool. You should run libtoolize for that. In fact, IIRC, au

Re: Automake security problem

2000-03-01 Thread Alexandre Oliva
On Mar 1, 2000, Jim Meyering <[EMAIL PROTECTED]> wrote: > Don't use `ln' (which was just a space optimization anyway) A worthwhile optimization, IMO. There are some `find' hacks in the `dist' rules to avoid modifying the permissions in the source tree, but, unfortunately, they do not app

AC_PROG_LIBTOOL vs. AM_PROG_LIBTOOL in automake-1.4.a

2000-03-01 Thread mdejonge
Hi, I'm using automake-1.4a (obtained from the CVS repository) and encounter the following problem in combination with libtool: When using AM_PROG_LIBTOOL in configure.in, automake complains configure.in: 10: `AM_PROG_LIBTOOL' is obsolete, use `AC_PROG_LIBTOOL' instead But when using AC_PROG

Re: Automake security problem

2000-03-01 Thread Jim Meyering
Bob Friesenhahn <[EMAIL PROTECTED]> writes: | I am using CVS automake. After doing a 'make dist', I find that all | the files in my source directories are marked world read/write. This | makes it easier for others to add trojan horses to the code I write. Ick. Thanks for providing the impetus