Please unsubscribe me from this maillist...
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
> "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
> "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 imple
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, pyth
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
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 o
Rüdiger Kuhlmann <[EMAIL PROTECTED]> writes:
> 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 t
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 overcome. However
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
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 2G
> "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
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
skyper wrote:
>
> Hi
>
> i updated to autoconf-2.50 and tried the following test
> configure.in file:
>
> # cat >configure.in< > 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:
>>> "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 the
Russ Allbery writes:
> What I'd love to see is a way to pass the configure script a whole list of
> directories into which software may be installed, not just /usr/local and
> /usr/pubsw but also /usr/pubsw/apps/db3 and /usr/pubsw/apps/openssl and
> other directories that have a lib and include s
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 f
Hi
i updated to autoconf-2.50 and tried the following test
configure.in file:
# cat >configure.in< 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
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 co
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 wil
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 /u
> "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 r
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
23 matches
Mail list logo
