> Would it somehow be possible via an extra
argument or otherwise to add the ability to instruct those macros to use
the C++ compiler instead?
A hack: Look for C++ first then CC=$CXX?
- Rhys
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.o
> YMMV.
My mileage has been great thus far in a mixed git/svn environment.
Thank you for the useful tool.
- Rhys
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
> My use case in Buildroot is very different: we build potentially
> several dozens of different software components, each time with a
> different toolchain/environment. So we're almost never rebuilding with
> the exact same configuration, and therefore using a cache doesn't
> really work for our u
On Fri, Jun 6, 2014 at 9:48 AM, Paul Eggert wrote:
> veerrry common for 'configure' to be an unreasonably large part of the build
> process
But is an unreasonably large part of a reasonably long build process?
You quote a from-scratch build with configure being an order of
magnitude slower than p
> Wouldn't it be time to
> think about moving autoconf to a more parallel logic, where N tests
> could run in parallel in sub-processes?
I only find the configure process to be frustratingly slow when run
against compilers with license keys or with checks accessing network
storage. Running those
Hi Raphael,
(Resurrecting:
https://lists.gnu.org/archive/html/autoconf/2009-12/msg00056.html)
> I would like to submit the attached script to your collective attention. This
> is a helper script to automate handling project version numbers in a mixed
> autoconf / svn / git-svn environment.
Th
> Is there some way to tell AC_OUTPUT that _AC_OUTPUT_SUBDIRS has
> already been run? Possibly by redefining it to be empty?
I am trying trickery like just setting 'no_recursion=yes' just before
AC_OUTPUT to suppress the recursion along with some checks to make
sure that subdirs hasn't changed in
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-subconfigure beha
> My TESTS= targets can accept flags and data and I would like to pass things
> like files "-f test.dat" to them,
>
> How do I do that?
I am unsure if it is the party line answer, but I've generally written
a script invoking the binary and added that script to TESTS and
dist_check_SCRIPTS.
For e
> Is 'make check VERBOSE=1' what you're after?
That is exactly it. Sorry to have missed this in the manual. Thank you Peter.
- Rhys
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
Is there some variant of 'make check' that, for the parallel test
harness, will dump the contents of the relevant test-suite.log on
failure?
I ask because, depending on the project build particulars
(non-recursive, deeply recursive, etc), running 'make check || cat
test-suite.log' isn't a one-size
> I think there would need to be a higher-level "abstract"
> know (low, medium, high), and then a way to add specific
> compiler-specific options for specific circumstances.
>
> Something like:
> AC_PROG_CC_WARNINGS_ADD([clang],
> [-Wtautological-constant-out-of-range-compare -Wpointer-sign
> -Wf
> How can I achieve this with autoconf? I mean: I know how to write a test
like
>
> AC_CHECK_HEADER(superlu/slu_util.h, foo, bar),
>
> but how do I obtain (in 'foo') the path relative to which the file
superlu/slu_util.h
> was found?
Use the optional third and forth arguments. Run the macro severa
> One of the simplest extensions is an intrinsic module called iso_fortran_env
> which can be included in a fortran program with the use statement.
> The test code would look like this,
>
> program test
> use iso_fortran_env
> write(*,*) 'hello'
> end program
As a nit, I'd use "use, intrinsic :: i
>> On 03/02/2012 05:45 AM, Eric Blake wrote:
>>> The Autoconf team is considering releasing only .xz files for 2.69;
>>> if this would be a hardship for you, and you need the .gz or .bz2
>>> release, please speak up now.
Would only having xz introduce a chicken-and-egg bootstrapping
problem? I no
> I have a configure script that uses acx_mpi from the macro archive. It
> then wants to test some features of the MPI implementation such are whether
> mpi-io is supported, and I am trying to improve these tests to add them to
> the archive. So ACX_MPI sets MPICC or MPIFC or MPIF77 and MPILIB
>> With a same set of autoconf/automake files, how to I distribute my
>> program that allows user to build it with or without debug code
>> enabled?
> Of course you can write (or find and copy) some Autoconf M4 code to
> do some or all of the above automatically depending on the presence
> of conf
Hi all,
Resurrecting an old thread regarding using libtool for configure-time testing.
The motivation was to use libtool to work around -R-like options which break
compilation on certain platforms when not properly protected. In particular,
my response draws from these two messages...
http:/
(Unsure to which list this thread response should be sent due to an
earlier missing cross-post...)
On 06/15/2011 12:20 PM, Peter Simons wrote:
>> Now, I wonder what to do about AX_MPI. It seems to me like your
>> macros make that older version obsolete. Do you think we should
>> deprecate AX_MPI a
Hi David,
On Wed, Jan 12, 2011 at 3:31 PM, David Bruce wrote:
> make[1]: Leaving directory `/usr/local/src/git/t4kcommon/build'
> rm -f config.status config.cache config.log configure.lineno
> config.status.lineno
> rm -f Makefile
> ERROR: files left in build directory after distclean:
> ./t4k_co
Hi Ralf,
>> Can anyone recommend a macro for obtaining a kind parameter value in
>> Fortran 90?
> Have you looked at the Autoconf Macro Archive?
Nothing there jumped out as a good starting point.
>> The check would be like AC_SIZEOF, but instead of returning the size
>> it would return the kind
Can anyone recommend a macro for obtaining a kind parameter value in
Fortran 90? Or a macro where I might look for how to roll my own?
The check would be like AC_SIZEOF, but instead of returning the size
it would return the kind parameter value (an integer). AC_COMPUTE_INT
would be perfect, but
> I have started using autotools for the C++ applications I create (very
> much as an amateur). I typically use assert statements during
> development, and would disable these by using -DNDEBUG when the release
> version is built. How should I configure things so that when a user
> installs from th
>> Your use of the term "::malloc" makes it sound like this test is
>> somehow related to C++ rather than C.
> So, deeply in boost (which I considered serious work up to now)
> some call to malloc() is made.
Any chance this is merely a #include vs #include issue?
- Rhys
_
> The most popular scenario I think is: the pkg-config
> itself is bundled to the system (/usr/bin/pkg-config etc)
> but the users install their own libraries to non-system
> directory (e.g. /usr/local/xxx), and the users slipped
> to set PKG_CONFIG_PATH manually.
Definitely very useful, especiall
Hi all,
Any suggestions for how to achieve sort-by-version in a portable way?
'ls -v' does exactly what I need, but doesn't look to be a standard
argument.
- Rhys
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autocon
> If I run configure from within trunk, make works successfully, but if
> I do a VPATH build I get errors because config.h is not located. If I
> change ' #include "config.h" ' to ' #include ../config.h" ', it works
> as either a VPATH build or an in-tree build. I'm not sure this is the
> right
Hi Ralf,
>> The easy way to eliminate the warning is to include
>> AC_CANONICAL_TARGET early on in my configure.ac.
> Why do you think it would be a problem for users of your macro to follow
> the above advice?
The solution does work . I had some confusion about getting
AC_CANONICAL_TARGET earl
Hi all,
I've got a macro that needs $target_cpu which is available from
AC_CANONICAL_TARGET. Within my macro I use
AC_REQUIRE([AC_CANONICAL_TARGET]) which triggers the following
warning:
configure.ac:47: warning: AC_ARG_PROGRAM was called before AC_CANONICAL_TARGET
../../lib/autoconf/general.m4:
Hi Philip,
There's a Doxygen macro up at the Autoconf Macro Archive:
http://autoconf-archive.cryp.to/ax_prog_doxygen.html
Might take some setup to get going, but it looks like it some sample rules
that you could include within your Makefile.am's.
- Rhys
On Mon, Mar 23, 2009 at 6:34 AM, Philip H
This may do what you need:
http://autoconf-archive.cryp.to/ax_compiler_vendor.html
- Rhys
On Fri, Feb 20, 2009 at 4:43 PM, aaragon wrote:
>
> Hi everyone,
>
> I was wondering if there is an easy way to test if using the C++ intel
> compiler (icpc). I've been trying to see the values of variable
Hi Umut,
Sounds like you're looking for either a VPATH Build (
http://www.gnu.org/software/libtool/manual/automake/VPATH-Builds.html) or
else to change the installed binary locations using ./configure --prefix=DIR
and friends. Both should work out of the box.
- Rhys
On Tue, Aug 19, 2008 at 11:5
Final comment:
The recreate behaves as I expect if I modify gl_ABSOLUTE_HEADER to use
AC_CHECK_HEADERS instead of AC_CHECK_HEADERS_ONCE.
My stupidity for not seeing the _ONCE variant buried in there. Sorry.
- Rhys
On Thu, Aug 14, 2008 at 11:34 AM, Rhys Ulerich <[EMAIL PROTECTED]>wrote:
p the function's code
into the main configure.ac file.
I'll modify my use of gl_ABSOLUTE_HEADER to get past this one. I'll also
email [EMAIL PROTECTED] to report it. A note in the gl_ABSOLUTE_HEADER
macro source might save someone else some time.
Thanks,
Rhys
On Thu, Aug
Me again,
How many chickens must I sacrifice for AC_CHECK_HEADER to notice that I've
modified CFLAGS/CPPFLAGS within my configure script?
Within an m4 macro and using autoconf version 2.62:
# Code to save LDFLAGS/CPPFLAGS/etc.
>
LDFLAGS="-L${trilinos_libdir} $LDFLAGS"
>
CPPFLAGS=
Some variation on the AC_COMPILE_WARNINGS macro at the cryp.to archive may
be what you want (http://autoconf-archive.cryp.to/ac_compile_warnings.html).
There are several other warnings-related macros there.
- Rhys
On Wed, Aug 13, 2008 at 7:07 AM, Thien-Thi Nguyen <[EMAIL PROTECTED]> wrote:
> Wha
Ralf,
You rock.
- Rhys
On Tue, Aug 12, 2008 at 4:06 PM, Ralf Wildenhues <[EMAIL PROTECTED]>wrote:
> Hi Rhys,
>
> * Rhys Ulerich wrote on Tue, Aug 12, 2008 at 10:57:34PM CEST:
> >
> > In my configure.ac script, I know a header works from an AC_CHECK_HEADER
> &g
Hi all,
In my configure.ac script, I know a header works from an AC_CHECK_HEADER
invocation.
I want to get its absolute pathname.
Anyone know of a way to get at a header path similar to the way AC_PATH_PROG
works?
Thanks,
Rhys
___
Autoconf mailing list
Thanks for the response Eric, and for catching the quoting error in my
example.
| AC_REQUIRE([AC_CONFIG_AUX_DIR_DEFAULT])
>
> This is an undocumented macro. I'm not sure what you are trying to
> accomplish by using it here.
>
> ...
>
> What's wrong with doing this in configure.ac:
>
> AC_CONFIG_
'afternoon,
I'm putting together a (hopefully reusable) macro the requires a script in
my AC_CONFIG_AUX_DIR directory:
AC_DEFUN(AC_FOOBARBAZ,[
#...
AC_REQUIRE([AC_CONFIG_AUX_DIR_DEFAULT])
AC_REQUIRE_AUX_FILE([tex-it])
AC_SUBST(ac_aux_dir)
# Output a script that will later invoke $(ac_aux_dir)/tex
40 matches
Mail list logo
