On 11 November 2015 at 16:51, Gavin Smith wrote:
> It also needs to be resilient against failure of the subsidiary
> configure script. This happened due to the AC_PROG_CC macro
> discovering that the C compiler didn't exist, or didn't work. This
> compiler was the one that that Perl said it was co
I would like to configure in a subdirectory of a project.
AC_CONFIG_SUBDIRS accumulates its arguments and does them all at the
end, but I'd like it to be done right away.
I searched the archives of the mailing list and found a few
discussions, e.g.
http://lists.gnu.org/archive/html/autoconf
Dear list,
I have a question, sorry to bother.
I've been trying to compile mpir using android cross compiler.
I've been using this script to set enviroment
http://pastebin.com/CdXcZnJM
This project uses AC_CONFIG_SUBDIRS to configure sub package 'yasm' in
configure.ac:
--c
On 12/03/2014 04:24 AM, Václav Zeman wrote:
> On 3 December 2014 at 11:32, Thomas Jahns wrote:
>> Hello,
>>
>> I noticed having a default prefix of . causes AC_CONFIG_SUBDIRS to fail.
>>
>> Is this a bug in AC_PREFIX_DEFAULT (or its documentation) or in
>> A
On 3 December 2014 at 11:32, Thomas Jahns wrote:
> Hello,
>
> I noticed having a default prefix of . causes AC_CONFIG_SUBDIRS to fail.
>
> Is this a bug in AC_PREFIX_DEFAULT (or its documentation) or in
> AC_CONFIG_SUBDIRS?
>
> Regards, Thomas
>
> P.S
Hello,
I noticed having a default prefix of . causes AC_CONFIG_SUBDIRS to fail.
Is this a bug in AC_PREFIX_DEFAULT (or its documentation) or in
AC_CONFIG_SUBDIRS?
Regards, Thomas
P.S.: the failure looks like this
config.status: executing depfiles commands
=== configuring in yaxt (/path
s hasn't changed in the meantime...
AC_CONFIG_SUBDIRS([sub1])
AC_CONFIG_SUBDIRS([sub2])
early_subdirs="$subdirs"
_AC_OUTPUT_SUBDIRS
dnl ...
dnl Arbitrary things
dnl ...
if test "$early_subdirs" != "$subdirs"; then
AC_MSG_ERROR([Sanity error: "$early_su
Hi all,
I've got an autoconfiscated project and two subprojects where I'd like
to use AC_CONFIG_SUBDIRS. The subprojects configure scripts perform
some nontrivial checks, and dump their results into pkg-config files
sub1.pc and sub2.pc. The usual,
wait-until-AC_OUTPUT-to-invoke-su
roach you were suggesting; using
> the
> installed package if it's there then falling back to a
> sub-package if
> it's not. I'll take a look at your macro. Thanks much.
>
>
> Trying to use your macro today simply replacing my AC
On Sat, Apr 7, 2012 at 10:37 AM, Richard Ash wrote:
> On Fri, 2012-04-06 at 22:01 -0400, Paul Dugas wrote:
>> I'm trying to use the pkg-config script provided by a sub-package to
>> make appropriate additions to CFLAGS, LDFLAGS and LIBS for the parent
>> package and have discovered the actual sub-
On Fri, 2012-04-06 at 22:01 -0400, Paul Dugas wrote:
> I'm trying to use the pkg-config script provided by a sub-package to
> make appropriate additions to CFLAGS, LDFLAGS and LIBS for the parent
> package and have discovered the actual sub-package configuration is
> delayed until the AC_CONFIG_FIL
I'm trying to use the pkg-config script provided by a sub-package to
make appropriate additions to CFLAGS, LDFLAGS and LIBS for the parent
package and have discovered the actual sub-package configuration is
delayed until the AC_CONFIG_FILES call. I found a 2008 post where
someone had run into the
Hi Ralf,
> > $ autoconf
> > configure.ac:1: warning: AC_INIT: not a literal: 2.48++ (2010-07-03)
> >
> > Yes, in some packages, the version number consists of two parts, separated
> > by
> > a space.
>
> The space isn't a what triggers the warning here, it's the parentheses
> around the dat
- "Mike Frysinger" wrote:
> On Saturday, July 03, 2010 15:59:35 Eric Blake wrote:
> > Unfortunately, I'm not in a position to release 2.67 for another
> > two weeks; if it helps, then hopefully distro packagers will
> > pick this up before they build 2.66 into a distro.
>
> does that include
On Saturday, July 03, 2010 15:59:35 Eric Blake wrote:
> Unfortunately, I'm not in a position to release 2.67 for another
> two weeks; if it helps, then hopefully distro packagers will
> pick this up before they build 2.66 into a distro.
does that include pushing fixes to git ? usually i cut upstr
- "Bruno Haible" wrote:
> Hi,
>
> In the newest autoconf 2.66, AC_CONFIG_SUBDIRS warns when it is
> invoked with
> more than one directory. But this way of invoking it is supported, see
> the doc:
Thanks for the report, and sorry for the regression. Does this
Hello Paul,
* Paul Dugas wrote on Tue, May 11, 2010 at 04:49:28AM CEST:
> I have a project that's using AC_CONFIG_SUBDIRS to configure a separately
> maintained library. The library is a C++ wrapper for another C library.
> Linking against the C++ wrapper library requires also l
I have a project that's using AC_CONFIG_SUBDIRS to configure a separately
maintained library. The library is a C++ wrapper for another C library.
Linking against the C++ wrapper library requires also linking against the C
library. i.e. "prog" has "libfooxx" in a subdir
On Sat, 2008-05-24 at 09:41 +0200, Ralf Wildenhues wrote:
> Hello Richard,
>
> * Richard Ash wrote on Fri, May 23, 2008 at 11:31:39PM CEST:
> > I seem to have hit a fundamental problem with the way AC_CONFIG_SUBDIRS
> > that seems to make it most of the way to useless if
Hello Richard,
* Richard Ash wrote on Fri, May 23, 2008 at 11:31:39PM CEST:
> I seem to have hit a fundamental problem with the way AC_CONFIG_SUBDIRS
> that seems to make it most of the way to useless if you want to also use
> pkg-config. Basically, it runs the configure scrip
I seem to have hit a fundamental problem with the way AC_CONFIG_SUBDIRS
that seems to make it most of the way to useless if you want to also use
pkg-config. Basically, it runs the configure scripts in sub-directories
after my main configure script has finished, which is useless because I
want
t, and then downloads the .tar.gz dependency, untars
> > it, and configures it. Currently I ./configure the sub projects manually by
> > calling the sub projects ./configure directly. However, using
> > AC_CONFIG_SUBDIRS
> > might be better, because I think it'll pass do
sub projects manually by
> calling the sub projects ./configure directly. However, using
> AC_CONFIG_SUBDIRS
> might be better, because I think it'll pass down the top-level configure
> options
> to the subproject.
Right. It assumes some things though: for example, that
Hi,
I'd like to use AC_CONFIG_SUBDIRS, but would like to understand more
clearly what it does. I have a setup where you check out a project and
then you have a top-level ./configure script.
When you run the top-level configure script, it determines what libraries you
need to build the pr
Hello,
On Sat, Sep 23, 2006 at 03:05:53PM +0530, Sanjaya Ratnaweera wrote:
> ./configure --enable-test=yesin root directory I assign
>
> TESTS="tests".
>
> Can I use that $TESTS variable inside a sub project?
first, please note that the option --enable-test=yes is passed to
Hi all,
I have a project which has sub projects. I'm using AC_CONFIG_SUBDIRS to
configure them at one time.
Main project
|-sub project 1
|-sub project 2
|-sub project 3
Can a sub project use a variabl
I have had to do this before, including cases where some of the
subdirs did not use autoconf, or used different (older) versions of the
auto* tools than I was running.
I went to a model where I used variables and an "include" file to get the
names of the desired packages (and their versions). IE,
Hello,
On Wed, Oct 19, 2005 at 03:16:05PM -0400, tom fogal wrote:
> We have a growing selection of utilities of special purpose interest to
> everyone else making the decision of whether or not to bundle several
> packages together (probably via AC_CONFIG_SUBDIRS, but not
> necessa
'll just cut it short -- how is
everyone else making the decision of whether or not to bundle several
packages together (probably via AC_CONFIG_SUBDIRS, but not
necessarily)? I'm interested in maintainability, understandability,
and avoiding 'code rot' (or build system r
On Fri, 2005-06-24 at 14:59 +0200, Harald Dunkel wrote:
> Hi folks,
>
> I've got a question about AC_CONFIG_SUBDIRS: How can I
> pass a different --prefix to the "sub-configure", e.g.
> '$(prefix)/submodule' ?
AFAIK, you can't.
To work ar
Hi folks,
I've got a question about AC_CONFIG_SUBDIRS: How can I
pass a different --prefix to the "sub-configure", e.g.
'$(prefix)/submodule' ?
Regards
Harri
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
Ralf Corsepius ([EMAIL PROTECTED]) wrote:
Hi Ralf!
> IMO, you have tripped a bug in autoreconf.
[...]
> The scenario you describe is supposed to work out of the box and it
> probably does when not using aclocal, autoconf and automake directly
> instead of invoking autoreconf.
Well, I was also
On Sat, 2005-06-04 at 10:40 +0200, Gour wrote:
> Hi!
> AC_CONFIG_SUBDIRS([clisp-2.33.2])
>
> but autoconf complains that clisp directory does not contain
> configure.ac(in):
>
> autoreconf-2.59: `configure.ac' or `configure.in' is required
IMO, you have tripped
ngine for the rest
of the package.
I have tried to use AC_CONFIG_SUBDIRS in my top-level configure.ac as:
AC_CONFIG_SUBDIRS([clisp-2.33.2])
but autoconf complains that clisp directory does not contain
configure.ac(in):
autoreconf-2.59: `configure.ac' or `configure.in' is required
I r
e up things like --help=recursive, you could just call the inner
``configure'' outright and stop using AC_CONFIG_SUBDIRS. That does affect your
users, though. Keeping the bootstrap script until released versions of Autoconf
have corrected this behavio
Hi,
I have a project that uses AC_CONFIG_SUBDIRS with a subdirectory that
includes a subpackage (ffmpeg) that has it's own hand coded configure
script. My project does use the autotools and has a customary
./boostrap.sh script, as per the autotools book. This has been working
fin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Braden,
On 29 Apr 2004, at 19:35, Braden McDaniel wrote:
Some issues related to use of CVS libtool with AC_CONFIG_SUBDIRS:
1. libtoolize doesn't appear to recurse into AC_CONFIG_SUBDIRS.
Should
it? Or is this autoreconf's job?
Au
Hi,
I'm interested in bundling a library with another package. I have it set up to
use the system library if available, but if not I'd like to use the version
I'm bundling.
The trick is that I'd like to pass a couple of options to the bundle:
--disable-shared and --disable-pthread.
How can I pas
hi there,
some weeks ago we discussed ways to enhance the AC_CONFIG_SUBDIRS
macro, to be able to let subdir configure calls fail in a controlled
way. What happened to that feature request ? Do you plan to make
enhancements in that direction ?
The situation is this: I'm working on the
=${enable_gui}
],ac_build_gui=no)
echo ${ac_build_gui}
if test "x${ac_build_gui}" = "xyes"; then
echo "Running configure in gui..."
AC_CONFIG_SUBDIRS(gui)
fi
The idea is that if the user enables the gui, configure should run
configure in the gui directory. H
Akim Demaille wrote:
> | And the subdir configure is called with:
> |
> | ./configure --host=i686-mingw32msvc host_alias=i686-mingw32msvc
> | --target=i386-mingw32msvc target_alias=i386-mingw32msvc
> | --build=i386-linux build_alias=i386-linux
> |
> |
> | This causes the subdir configure to fai
| Earnie Boyd wrote:
| > Are you using Cygwin or are you cross compiling using Linux? It appears
| > to me as if you've used the wrong switch, you want --target not
| > --build. I may be wrong, I've never cross compiled.
| > If you're using Cygwin you need to:
|
| > CC='gcc -mno-cygwin'
|
| >
Earnie Boyd wrote:
> Are you using Cygwin or are you cross compiling using Linux? It appears
> to me as if you've used the wrong switch, you want --target not
> --build. I may be wrong, I've never cross compiled.
>
> If you're using Cygwin you need to:
>
> CC='gcc -mno-cygwin'
> configure --ho
n.cpp
> ...
>|
>|- libltdl/
>|
> ...
>|- configure.in
>|- configure
>|- ltdl.c
>
> This is an over simplification, but you get the idea. The main
> configure script has a line like "AC_CONFIG_SUBDIRS(libltdl)". This
>
|- ltdl.c
This is an over simplification, but you get the idea. The main
configure script has a line like "AC_CONFIG_SUBDIRS(libltdl)". This
works in most situations, when I am just passing --enable/--disable
arguments to configure. But when I pass a build type for example:
.
I am using autoconf 2.52. I have a project that requires a seperate
configure script in a child directory. I specify its directory in
AC_CONFIG_SUBDIRS. In most cases everything works properly: I run the
main configuration script which, when complete, runs the other
configure. I have
I call AC_CONFIG_SUBDIRS in my configure.ac file to run configure in a
subdirectory. Unfortunately, configure only runs other configure scripts
at end of the main configure script. The problem is that the subdir's
configure script writes a file which needs to read back to find out ho
configuration and compilation of pkgA using AC_CONFIG_SUBDIRS(pkgA).
> Therefore in src directory, I run ./configure, followed by make --- all
> works well. On Platform A, pkgA is configured and compiled automatically.
>
> Now, for Platform B, I need to add switches to the configure
thers do not.
When src/configure is run on Platform A it will identify that pkgA is
unavailable, but recognizes that the source (../pkgA) exists and therefore will
schedule the configuration and compilation of pkgA using AC_CONFIG_SUBDIRS(pkgA).
Therefore in src directory, I run ./configure, follow
>>>>> "Paul" == Paul Martinolich <[EMAIL PROTECTED]> writes:
Paul> I have a configure.ac in which I conditionally configure
Paul> additional sources that have their own ./configure scripts.
Paul> Using AC_CONFIG_SUBDIRS works great. But, now I'd lik
I have a configure.ac in which I conditionally configure additional
sources that have their own ./configure scripts. Using AC_CONFIG_SUBDIRS
works great. But, now I'd like to pass some configure options that I
don't use in my top-level configure. How can I pass these to the
51 matches
Mail list logo
