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 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
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 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
> 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 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
> 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
>> 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
_
> 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
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
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
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
(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 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:/
>> 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
> 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
>> 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
> 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
> 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
> 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
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
> 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
> 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
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
> 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 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
> 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
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
> 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
> 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
> 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
'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
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_
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
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
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
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=
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
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:
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
40 matches
Mail list logo
