Bonjour,
Avez vous pensé à vos cartes de visite ?
www.cartevisite.com, le leader des cartes de visite sur Internet vous propose une
réduction découverte de 20 F sur l'impression de vos prochaines cartes de visite.
A partir de 339 Fht pour 250 exemplaires en couleur sur papier de qualité en
Hello!
The conditions under which Automake installs and uses the depmod script
are different. It can actually happen that it's not installed but
configure tries to use it.
For example, GNU Midnight Commander is using Automake only on the top
level and for data directories. Automake doesn't see
On Thursday 17 May 2001 4:19 am, Tom Tromey wrote:
Reinhard == Reinhard Mller [EMAIL PROTECTED] writes:
Reinhard I am just reading the GNU coding standards (chapter 7.2.5 -
Reinhard Standard Make Targets) and I see that it's recommended that
Reinhard maintainer-clean should not delete
On May 17, 2001, Tom Tromey [EMAIL PROTECTED] wrote:
Sometimes I wonder if this is really the right thing to do.
Perhaps it should be an option?
I often use read-only srcdir myself, so I'd like to have this
possibility. Anyway, since we do update files that are part of the
distribution
On May 17, 2001, Pavel Roskin [EMAIL PROTECTED] wrote:
AM_DEPENDENCIES should be more quiet if it cannot find depcomp.
I think this would be a good compromise. Assuming depmode=none would
be fine, in this case.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red
Gary V. Vaughan wrote:
That's interesting. I have always tried to have maintainer-clean revert the
source tree to the state it was in when freshly checked out of CVS. Giving
this some thought, it seems to be something that can't easily be fully
automated by automake since people have
Sure, how can I help?
I bet the first thing is to get CVS automake on that box...
Harlan
On Thu, 17 May 2001 18:03:33 -0600, Tom Tromey [EMAIL PROTECTED] said:
Paul == Paul F Kunz [EMAIL PROTECTED] writes:
Paul bundle: rm -rf */*.o c++ -bundle
Paul -I/System/Library/Frameworks/JavaVM.framework/Headers \ -I. -o
Paul libhippoplot.jnilib -framework JavaVM \ jni/*.cxx pattern/*.cxx
Tom == Tom Tromey [EMAIL PROTECTED] writes:
Harlan == Harlan Stenn [EMAIL PROTECTED] writes:
Harlan Second, there seems to be a dependency problem.
Tom I was able to write a test and reproduce this.
Tom I'll check the test in soon.
I was mistaken -- I was able to write a broken test which
Harlan == Harlan Stenn [EMAIL PROTECTED] writes:
Harlan 2 problems. First, since ../util/ansi2knr isn't found, an
Harlan empty foo_.c file gets created. I think the line needs
Harlan ... || rm foo_.c stapled on the end.
I agree.
Harlan Second, there seems to be a dependency problem.
I was
adl == Alexandre Duret-Lutz [EMAIL PROTECTED] writes:
adl Some weeks ago Bruno Haible reported (in private mail) that
adl running `make dist' with srcdir != builddir could produce
adl distributions which are not up-to-date, especially if you have
adl generated files like bison parsers
adl This
Paul == Paul F Kunz [EMAIL PROTECTED] writes:
Paul So on a Mac OS X platform, I would want effiectively the
Paul following...
Paul cd hippo; make # compiles the Java
Paul cd jni; make # creates JNI headers and compiles the C++ in jni/
Paul make bundle
SUBDIRS = hippo jni .
Paul And I
adl == Alexandre Duret-Lutz [EMAIL PROTECTED] writes:
adl 2001-03-06 Alexandre Duret-Lutz [EMAIL PROTECTED]
adl* install.am (install-strip): Set INSTALL_PROGRAM_ENV if STRIP is
adlnot empty.
adl* m4/strip.m4 (AM_PROG_INSTALL_STRIP): Set INSTALL_STRIP_PROGRAM
adlto install-sh
adl == Alexandre Duret-Lutz [EMAIL PROTECTED] writes:
adl I'm not sure this is the right place to document this.
adl 2001-03-06 Alexandre Duret-Lutz [EMAIL PROTECTED]
adl* automake.texi (Requirements): Document the use of the STRIP
adlvariable in cross-compilation environments.
Looks
edward == edward [EMAIL PROTECTED] writes:
I'm finally reading this thread.
I haven't finished it yet, so what I say may make little sense :-(
edward # FIXME: nodist.
edward push_dist_common ($pfx . $base . '.' . $ext);
edward commenting out the last line removes foo.c (which is
Pavel == Pavel Roskin [EMAIL PROTECTED] writes:
Pavel I've written depcomp2.test that demonstrates the problem.
Thanks, I'm checking this in.
Tom
Paul == Paul F Kunz [EMAIL PROTECTED] writes:
Paul bundle:
Paul rm -rf */*.o
Paul c++ -bundle -I/System/Library/Frameworks/JavaVM.framework/Headers \
Paul -I. -o libhippoplot.jnilib -framework JavaVM \
Paul jni/*.cxx pattern/*.cxx reps/*.cxx src/*.cxx transforms/*.cxx \
Paul
Pavel AM_DEPENDENCIES should be more quiet if it cannot find depcomp.
Alexandre I think this would be a good compromise. Assuming
Alexandre depmode=none would be fine, in this case.
This sounds good to me. I'm checking this in.
Tom
Akim == Akim Demaille [EMAIL PROTECTED] writes:
Akim Nonetheless, I keep on thinking this is overkill, and would like to
Akim resubmit my proposal, part of the aforementioned thread:
Akim http://sources.redhat.com/ml/automake/2001-03/msg00151.html
I'd still prefer not to do this. I think
Gary == Gary V Vaughan [EMAIL PROTECTED] writes:
Gary I have always tried to have maintainer-clean revert the source
Gary tree to the state it was in when freshly checked out of CVS.
This is easy enough to do; there is a tool in the `cvsutils' (Pavel's,
not Alexandre's) which will remove
Harlan == Harlan Stenn [EMAIL PROTECTED] writes:
Harlan Sure, how can I help?
Harlan I bet the first thing is to get CVS automake on that box...
I'm afraid so.
But if you could just get the cvs automake anywhere, you could set up
a similar test case which would show the failure.
What I'd
I recall it failing on openBSD 2.8.
Rob
Robert == Robert Collins [EMAIL PROTECTED] writes:
Robert I recall it failing on openBSD 2.8.
Cool.
Now, how can we fix it?
One idea would be to emit `.PRECIOUS: parse.c'. However, I don't know
if that will work with a non-GNU make. Would that work on OpenBSD?
(I don't have access to an
The failure is happening on a SunOS 4.1.3 box with cc and GNU make
(3.76.1). The build is being done outside of the source tree:
% mkdir A.`config.guess`
% cd !$
% ../configure
% make
As I recall, the problem did not happen on a 4.1.3 box with gcc and GNU
make 3.74 .
I'm trying to install
24 matches
Mail list logo
