Rasmus Tamstorf wrote:
> On Wed, 28 Feb 2001, Derek R. Price wrote:
>
> <--- snip --->
>
>> Maybe that's not exactly what you wanted, but Autoconf is already set up to handle
>it.
>> Note that all the source files not generated by configure will still be under
>topdir/,
>> not topdir/arch?,
On Wed, 28 Feb 2001, Derek R. Price wrote:
<--- snip --->
> Maybe that's not exactly what you wanted, but Autoconf is already set up to handle
>it.
> Note that all the source files not generated by configure will still be under
>topdir/,
> not topdir/arch?, and a properly constructed Makefile
Rasmus Tamstorf wrote:
> Hmmm ... I'm not sure I understand ...
>
> My 'configure' script is in 'topdir' (or preferably in 'topdir/config' but
> that's a different story).
Autoconf always assumes it is in topdir. I suspect there's no easy way to work around
that.
> Furthermore I'd like to be
Hmmm ... I'm not sure I understand ...
My 'configure' script is in 'topdir' (or preferably in 'topdir/config' but
that's a different story). Furthermore I'd like to be able to run
'configure' just once per platform, and then have it create the
appropriate subdirectories for each source directory.
No, really. In the scenario you describe, your build tree has simply become a
subdir of the source tree. Using your example, assuming that your configure
scripts are in topdir/src/package?, and ignoring the fact that cd probably isn't
going to open me a shell on another platform:
cd topdi
On Wed, 28 Feb 2001, Derek R. Price wrote:
> Rasmus Tamstorf wrote:
>
> > AC_OUTPUT([src/_$ARCH/Makefile:src/Makefile.in])
>
> You know, there's a much more painless way to do this. Autoconf already knows
> that if you:
>
> mkdir $ARCH
> cd $ARCH
> ../configure
>
> Then the build tree will
Rasmus Tamstorf wrote:
> AC_OUTPUT([src/_$ARCH/Makefile:src/Makefile.in])
You know, there's a much more painless way to do this. Autoconf already knows
that if you:
mkdir $ARCH
cd $ARCH
../configure
Then the build tree will be created automatically in and under the current
directory. That'
Hey,
Would it be possible/plausable/make sense to have this macro exit and
error or not run at all if it is used in conjunction with a C++
compiler? I know it should be fairly obvious that this is a C macro, but
it did cause me some funky problems for me when there were changes made to
the test
Akim,
Is this what you were expecting?
I did a fresh build of the latest autoconf ( did a cvs update moments
before building).
Harlan
---
% make check
...
% make check
...
mv testsuite.tmp testsuite
/bin/sh testsuite
Testing suite for GNU Autoconf 2.49d
==
Hey,
I have found what I think to be a bug in the debian autoconf package
v2.13-25.
The problem that I have occurs when I use the AC_C_CONST macro. I've
attached the code that both 2.13-23 and 2.13-25 generated when the
AC_C_CONST macro was defined in my configure.in. The following is a diff
Rasmus Tamstorf <[EMAIL PROTECTED]> writes:
>
> On some systems there are more variables which distinguish configurations
> than simply cpu, vendor and os. On mips and sparc for example you can
> build 32 or 64 bit code, and on, say, a mips R10K you can build your code
> using either the mips3 or
Alexandre Oliva <[EMAIL PROTECTED]> writes:
> On Feb 28, 2001, Akim Demaille <[EMAIL PROTECTED]> wrote:
>
> > I've received tons of bug reports about failures during the build
> > phase of a2ps, people complaining of my requiring yacc, lex, msg*
> > etc. I did not require it, everything was shi
On Feb 28, 2001, Akim Demaille <[EMAIL PROTECTED]> wrote:
> I've received tons of bug reports about failures during the build
> phase of a2ps, people complaining of my requiring yacc, lex, msg*
> etc. I did not require it, everything was shipped.
IIRC, the problem is that automake 1.4's AM_PROG
On Feb 28, 2001, Emiliano <[EMAIL PROTECTED]> wrote:
> Where should I be asking about the possibilities of -rpath?
In the linker manual? Maybe in the GNU libtool manual?
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cy
"Tim Van Holder" <[EMAIL PROTECTED]> writes:
> Note that the ';' still isn't needed:
>
> PATH="foo:bar" conftest
>
> behaves exactly like
>
> PATH="foo:bar"; conftest
>
> except that the former does not affect PATH after the command is run.
I agree, but I think it is wrong to ass
Alexandre Oliva wrote:
> This probably adds some -L/dir -llibname to LIBS. This affects the
> linker when it searches for a library at link time, but not the
> dynamic loader when it looks for the library at run time. If both
> libraries have the same SONAME (which seems to be the case, given t
Bob Proulx <[EMAIL PROTECTED]> writes:
> Agreed. But a few additional words. HP make is stock classic AT&T
> System V UNIX make. Which "should" be fine. It is not a bad make.
> It is just the very traditional UNIX version and limited by those same
> traditions. Unfortunately it is frozen in
Harlan, I think this will fix your issue. Thanks for the report!
Index: ChangeLog
from Akim Demaille <[EMAIL PROTECTED]>
* tests/atgeneral.m4 (AT_INIT): Warn when at-check-line is
missing.
* tests/tools.at (Syntax of the scripts): Use AT_CHECK to test
/bin/sh -
On Feb 27, 2001, Emiliano <[EMAIL PROTECTED]> wrote:
> I would just add a --with-libfoo option which adds $withval in front
> of $LIBS and $CPPFLAGS, but the compilation process picks up on the
> first lib anyway (as shown by ldd after compilation finished).
This probably adds some -L/dir -llibn
19 matches
Mail list logo
