Deal all
I refer to my earlier mails about problem with c++ dependencies. I don't
know whether this is a bug but I found out why I could not make
dependencies tracking working correctly.
My code consists of several directories
~
~/src
~/tests
and so on
~/Makefile.am does not contain so much
~
Is it ok for autoconf tests to create a C test program such as this
if ( == )
exit (0);
else
exit (1);
and check the exit status with AC_TRY_RUN, or may this fail on some
systems?
--
Martin Wilck <[EMAIL PROTECTED]>
Institute for Tropospheric Research, Permoserstr. 15, D-04318 Leipzi
[Crossposting to gcc-bugs.
Gcc's top-level Makefile invokes sub-makes with M4=m4. This overrides
autoconf's otherwise correct idea of what "m4" it should call.]
On Sat, 21 Oct 2000, Assar Westerlund wrote:
> Marco Franzen <[EMAIL PROTECTED]> writes:
> > When I configured autoconf, it looked for
Hello!
The easiest way to reproduce the endless loop in the testsuite on HP-UX
10.20 without GCC is:
AC_INIT
_AC_COMPUTE_INT_COMPILE(foo, ac_foo)
AC_OUTPUT
I don't remember what exactly the bundled compiler didn't like in the
expression that Autoconf wanted it to compile. I assume that compile
I've tried to set up aclocal.m4 to just m4_include the necessary
macro files, but I don't want to write explicit paths to the files
in /usr/local/share/aclocal/, and I can't get autoconf to make m4
search in that directory automatically. Any hints?
Lars J
I'm not entirely certain this is the right forum for this message,
because I don't know where this problem is coming from. Lately (and I
don't recall exactly when it started) I've been having a great deal of
trouble compiling things because the configure scripts keep defining
"HAVE_" macros for t
As far as I'm concerned, I'm lost. I'm no longer sure your problem is
really related to ${FOO=$bar}, or, more precisely, that it is *only*
related to this.
This debate already partly happened, see `config.status is broken
under Ultrix' on
http://sources.redhat.com/ml/autoconf/2000-01/t
Hello, Akim!
> As far as I'm concerned, I'm lost. I'm no longer sure your problem is
> really related to ${FOO=$bar}, or, more precisely, that it is *only*
> related to this.
I installed QNX currently distributed from the QNX site (uname -r shows 6.00)
and I couldn't reproduce the problem with
> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:
Pavel> I installed QNX currently distributed from the QNX site (uname
Pavel> -r shows 6.00) and I couldn't reproduce the problem with
Pavel> ${FOO=$bar}
You're impressive! Your testing is incredibly conscientious, and
therefore precious.
> "David" == David Morgan <[EMAIL PROTECTED]> writes:
>>
>> test s${CONFIG_FILES+et} = set || CONFIG_FILES=$config_files
Yes, sorry I forgot to include the quotes. I really meant this:
test "${FOO+set}" = set
which is used all over Autoconf. There is no reason to change this.
Hello!
One thing was broken recently:
/bin/sh -n autoconf
doesn't work on FreeBSD and QNX if autoconf is not in the current
directory. This patch should probably be reverted, at least partially:
2000-10-23 Akim Demaille <[EMAIL PROTECTED]>
* tests/tools.m4: Globally, don't use `../'
Refering to my earlier mail today,I have a comment about
.cpp.o:
source='$<' object='$@' libtool=no \
depfile='$(DEPDIR)/$*.Po' tmpdepfile='$(DEPDIR)/$*.TPo' \
$(CXXDEPMODE) $(depcomp) \
$(CXXCOMPILE) -c -o $@ `test -f $< || echo '$(srcdir)/'`$<
The name of the dependency file is connec
Patrick Guio <[EMAIL PROTECTED]> writes:
> I refer to my earlier mails about problem with c++ dependencies. I don't
> know whether this is a bug but I found out why I could not make
> dependencies tracking working correctly.
> My code consists of several directories
>
> ~
> ~/src
> ~/tests
> and
13 matches
Mail list logo
