Pavel == Pavel Roskin [EMAIL PROTECTED] writes:
Pavel First of all, I apologize for not having tested Autoconf on
Pavel OpenBSD 2.7 immediately before the release. I had tested it few
Pavel days before that, and it worked. I didn't check the latest CPP
Pavel changes. I accept full
Could somone specify what it is generic configure script would have to
find in order to think that the compiler I am using (gcc 2.95-3 on
sun/sparc solaris 8) is a cross-compiler? I have a fairly standard
install of everything, and I am using no proprietary tools with the
exception of a few in
You are doing fine, just some configure-checks are not ready
for cross-compiling, and that's what you are warned about.
Basically, the package that you are trying to cross-compile
has not been made ready for cross-compiling.
Two approaches:
a) learn about config.site or cache-file, and let it
Hi
i updated to autoconf-2.50 and tried the following test
configure.in file:
# cat configure.inEOF
AC_INIT(test.c)
AC_PROG_CC
AC_OUTPUT(Makefile)
EOF
# autoconf
configure.in:2: /usr/bin/m4: Bad expression in eval (bad input): 14 + len(C) + 1
configure.in:2: /usr/bin/m4: Bad expression in
On 23 May 2001 09:23:49 -0400, Derek R. Price wrote:
Russ Allbery wrote:
Derek R Price [EMAIL PROTECTED] writes:
By the way, I think I see what you're getting at here, but you really
spoil all of the automatic syntax coloration of my text editor since it
switches first based first
gd == Guido Draheim [EMAIL PROTECTED] writes:
[...]
gd b) bigendian-crosscompilecheck is a common problem, may be
gd the next generation autoconf will have the solution that
gd is currently present in in the autoconf-archive
BTW, now that 2.50 is out, maybe someone can review these
skyper wrote:
Hi
i updated to autoconf-2.50 and tried the following test
configure.in file:
# cat configure.inEOF
AC_INIT(test.c)
AC_PROG_CC
AC_OUTPUT(Makefile)
EOF
Your example worked on my system with gm4-1.4p and
autoconf 2.50. I used this for my configure.in:
sorry for the excessive addressing, but this topic touches all auto-tools.
I am in the process of convincing some people to move their Borland based
source code development to proprietary free models. As you may guess, this is
an extremly difficult task, requiring more pedagogical than technical
Martin == Martin Hollmichel [EMAIL PROTECTED] writes:
Before I address your points, or at least the ones I plan to address,
I thought first I would write my own critique of the auto tools.
While I do think that these tools have deep problems, I also think you
largely avoided mentioning them.
This is not restricted to borland compilers, there are quite
some C-compilers on unix-systems that quite some people like
to see supported, however most of the autotools developers
do live in a quite gnu'ish/gcc'ish environment, and every now
and then, a gmake'ish/gcc pecularity slips in that
de-lurking
Hi there!
Since we've autoconf 2.50 now, maybe it's time to come up with some
not-so-important issues. The problem at hand is that under AmigaOS, the
fork() function always returns EONOSYS (IIRC), in other words, there is no
spoon(), due to limitations that can't seriously be
Here's one I did for a project where I want to use 2.0. Since
python is still 1.5.2 on Debian, it had to be smart enough to see
that python's not 2.0...
It's not perfect... but it Works For Me(tm) ;-)
AC_DEFUN(jae_PYTHON,
[
# Try to find Python in the path
AC_PATH_PROG(PATH_TO_PYTHON, python)
On Thu, May 24, 2001 at 02:08:22AM +0200, Peter Eisentraut wrote:
Make config.status put all the configuration information into a single
makefile and have all the other makefiles include that one. It's saved me
many boring waits.
How do you reference the generated make file?
I'm thinking
Martin Hollmichel wrote:
Hi all,
I think the great misunderstanding is that the autotools are
not targeting real multiplatform development, but Unix centric
distribution of (GNU) OpenSource Software.
To do real multiplatform, multitools development the autotools
are difficult to use
On 23 May 2001, Tom Tromey wrote:
On to your complaints.
Martin * Mixing up debug and non debug build, do both causes double
Martin compile time, double diskspace and x-time more RAM for the
Martin debugger. Imagine to need 10 GB for Openoffice debug build and
Martin more than 2GB RAM to
Peter == Peter Eisentraut [EMAIL PROTECTED] writes:
Peter Make config.status put all the configuration information into a
Peter single makefile and have all the other makefiles include that
Peter one. It's saved me many boring waits.
That's an interesting idea. We could even implement this
Pavel == Pavel Roskin [EMAIL PROTECTED] writes:
Pavel I don't know whether Autoconf should be more robust or Automake
Pavel should take less (or more?) hackerish approach.
Probably the former.
Pavel Since Autoconf-2.50 has been released, it would be fair to drop
Pavel support for
Martin Hollmichel writes:
* changing a autotool file, then waiting for configure to write 1200
makefiles.
Make config.status put all the configuration information into a single
makefile and have all the other makefiles include that one. It's saved me
many boring waits.
--
Peter Eisentraut
Hello!
First of all, sorry for cross-posting, but as you will see it's hard to
decide whether Automake or Autoconf is guilty.
I have noticed Automake testsuite failures in distname.test, subobj5.test
and subobj6.test on OpenBSD 2.7 with the CVS head versions of Autoconf and
Automake.
It turns
This sounds familiar to me - I think I ran in to the same problem under
FreeBSD on a configure.in script that only wanted to find the X directories
(header and libs). I had to specify AC_PROG_CC to solve the problem.
H
20 matches
Mail list logo
