Re: PATCH: Copyright pedantry

2000-10-16 Thread Akim Demaille
Since this patch is trivial, and since I was wandering around here, I applied it. Akim

subdir4.test

2000-10-16 Thread Akim Demaille
This test fails with distcheck and not with check. My diagnosis is that it fails because with distcheck the source tree is read only, and therefore the `depcomp' which is imported by tests/defs is read only too: automake-1.4a/=build/tests % ls -l testSubDir/depcompnostromo 11:10 -r-

Re: CLEANFILES?

2000-10-16 Thread Ossama Othman
Hi, On Mon, Oct 16, 2000 at 03:59:31PM +0200, Patrick Guio wrote: > I try to use the configure tool to build my c++ code. When compiling with > a DEC/Digital Unix cxx compiler, templates are instantiated in a directory > called ~/cxx_repository (i.e. *.o files are created in this directory or > o

Re: CLEANFILES?

2000-10-16 Thread Ossama Othman
On Mon, Oct 16, 2000 at 10:02:02AM -0700, Ossama Othman wrote: > ## Clean up template repositories, etc. > clean-local: > -rm -rf .rpo ptrepository SunWS_cache Templates.DB That should have been "*.rpo," but you get the idea. :-) -Ossama -- Ossama Othman <[EMAIL PROTECTED]> Distributed

Re: [PATCH] compare header files before installing

2000-10-16 Thread Akim Demaille
This patch seems OK to me, but I'd appreciate if Alexandre, Tom, Pavel or Jim could confirm it's OK.

Re: [PATCH] SGI dependency tracking bugfix

2000-10-16 Thread Akim Demaille
| Re-resending this patch. | 2000-06-04 Morten Eriksen <[EMAIL PROTECTED]> | | * depcomp: fixed bug in sgi dependency tracking mode with | sourcecode files which does not contain any dependencies to other | source files. Thanks, applied. It looks sane, and you've bee

Re: Avoiding cross-dependencies for aclocal.m4

2000-10-16 Thread Akim Demaille
This guy looks good to me. Any objection? -- Hello! "ACLOCAL_AMFLAGS = -I ." causes circular dependencies. The patch fixes this problem, eliminates an extra occurence of acinclude.m4 and strips "./" from the remaining macro fi

Re: [PATCH] Dependency tracking for Microsoft Visual C/C++

2000-10-16 Thread Akim Demaille
| Hi, | this patch implements support for extracting dependency tracking | information by using the preprocessor mode of the Microsoft Visual | C/C++ compiler. Thanks, installed. Could someone explain to me why we launch it in background and then just wait for it to complete?

Re: Avoiding cross-dependencies for aclocal.m4

2000-10-16 Thread Alexandre Oliva
On Oct 16, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote: > This guy looks good to me. Any objection? Nope. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{cygnus.com, redhat.com} CS PhD student at IC-Unicampoliv

Re: [PATCH] Dependency tracking for Microsoft Visual C/C++

2000-10-16 Thread Alexandre Oliva
On Oct 16, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote: > | Hi, > | this patch implements support for extracting dependency tracking > | information by using the preprocessor mode of the Microsoft Visual > | C/C++ compiler. > Thanks, installed. > Could someone explain to me why we launch it i

Re: [PATCH] compare header files before installing

2000-10-16 Thread Alexandre Oliva
On Oct 16, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote: > This patch seems OK to me, but I'd appreciate if Alexandre, Tom, Pavel > or Jim could confirm it's OK. I have mixed feelings about this. At first, it may sound nice to not touch pre-existing files. However, think of someone that uses

Re: [PATCH] compare header files before installing

2000-10-16 Thread Raja R Harinath
Alexandre Oliva <[EMAIL PROTECTED]> writes: > On Oct 16, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote: > > This patch seems OK to me, but I'd appreciate if Alexandre, Tom, Pavel > > or Jim could confirm it's OK. > > I have mixed feelings about this. At first, it may sound nice to not > touch pr

Re: [PATCH] compare header files before installing

2000-10-16 Thread Alexandre Oliva
On Oct 17, 2000, Raja R Harinath <[EMAIL PROTECTED]> wrote: > Of course, it would be nice if 'install' in fileutils > could be extended to provide a --only-if-change option. Well, there's always move-if-change... But yes, that seems to be the way to go. We shouldn't change what isn't broken; g