quoted. otherflag, however,
was only a single token, and was therefore not quoted.
Can this kind of behavior be added to 2.52g?
Thanks.
{+} Jeff Squyres
{+} [EMAIL PROTECTED]
{+} Perpetual Obsessive Notre Dame Student Craving Utter Madness
{+} "I came to ND for 4 years and ended up staying for a decade"
Greetings.
I sent a message to this list about a month ago about what appears to be a
bug in autoconf 2.52g and got no responses. Can someone look this over
and make any suggestions?
Many thanks.
{+} Jeff Squyres
{+} [EMAIL PROTECTED]
{+} Perpetual Obsessive Notre Dame Student Craving Utter
- ##
configure: WARNING: ## Report this to http://www.open-mpi.org/community/help/
##
configure: WARNING: ##
------ ##
Thanks!
--
Jeff Squyres
Cisco Systems
_
me it happens:
You should use four-arguments AC_CHECK_HEADERS. Pass
AC_INCLUDES_DEFAULT as the fourth argument if you want to filter out
headers that cannot be compiled; pass [-] if you don't want that.
That is perfect -- thanks!
--
Jeff Squyres
Cis
der (and the
features that it provides)
- when compiling on this platform with this compiler, we just want
HAVE_INFINIBAND_DRIVER_H not defined, so that our C code can react
accordingly
In short: all we want is a simple "no" result from the test.
Do
header as present).
I used [AC_INCLUDES_DEFAULT]. This gave me:
- no warning
- use the compiler check
- test came back "no"
- hence HAVE__H was not set
Which is exactly what I wanted.
--
Jeff Squyres
Cisco Systems
___
Autoconf mailing l
/gitweb/?p=autoconf.git;a=commitdiff;h=66b800
I'm applying this (it has the benefit of reducing the number of
forks):
Excellent -- thanks Eric!
--
Jeff Squyres
Cisco Systems
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/ma
the current environment).
Here's a simple addition to the above code that will kick out the
==foo=bar case, although someone smarter than me with expr can
probably come up with something better:
-----
if test -z "$ac_envvar"; then
$as_echo "$as_me: error: inval
not a good / general solution. I've tried to
ask some assistance from Red Hat but I haven't been able to get a response.
Does anyone have any suggestions on how to solve this issue? I would find it
hard to believe that we're the only package running into this issue.
Thanks!
--
Hence: yes, it's our problem. Not Autoconf's.
Thanks for pointing me in the right direction, and sorry for the noise.
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
en -O0) to the Leopard built-in gcc will result in
one of these .dSYM directories:
# Just to be sure...
$ rm -rf *.dSYM
$ cat > mytest.c <
Hello there,
Jeff Squyres reported that on Mac OS X Leopard, some configure tests
create spurious warnings of the form:
rm: conftest.dSYM: is a dir
pace for
preprocessor macros, the only way to segregate them is by different
prefixes. But autoconf isn't even giving the user the option to do that
-- these macros will be named PACKAGE_FOO, regardless of what the user
wants.
Please please please give us a way to turn off (or put a prefix in f
f this burden?
Again -- the automake maintainers have seen the wisdom of not forcing
their own #defines upon program authors (i.e., the "no-define" option).
Can't autoconf do the same?
{+} Jeff Squyres
{+} [EMAIL PROTECTED]
{+} Research Associate, Open Systems Lab, Indiana University
{+} http://www.osl.iu.edu/
for AC_CONFIG_SUBDIRS because it wouldn't let my [optional]
subdirectory configure's fail gracefully. It would be highly preferable
if there was some kind of way of knowing whether the sub-configure failed,
and then allowing the top-level configure.ac to decide whether to continue
or not.
{+
efore the top-level
configure.ac) will immediately abort if any of the sub-configures return
anything other than a status of 0. So there's no possibility of the
top-level configure.ac checking to see if the sub-configure succeeded or
not -- if the sub-configure fails, everything aborts.
{+} Jeff Squy
s and fail cleanly
without having to configure themselves in a "pass through" mode.
I hope that makes sense. :-)
{+} Jeff Squyres
{+} [EMAIL PROTECTED]
{+} Research Associate, Open Systems Lab, Indiana University
{+} http://www.osl.iu.edu/
ed for a specific platform.
{+} Jeff Squyres
{+} [EMAIL PROTECTED]
{+} Research Associate, Open Systems Lab, Indiana University
{+} http://www.osl.iu.edu/
em is if the users also use autotools, the PACKAGE,
> VERSION, etc. symbols collide, and the current version of g++3.2
I agree. The programmer should be given the option to turn off the
PACKAGE/VERSION macros. Automake provides similar functionality --
autoconf should, too.
--
{+} Jeff Squ
y
can't we use the same mechanisms instead of having to roll our own?
AC_CREATE_PREFIX_CONFIG_H is not an option for me.
--
{+} Jeff Squyres
{+} [EMAIL PROTECTED]
{+} Research Associate, Open Systems Lab, Indiana University
{+} http://www.osl.iu.edu/
post this stuff here because it's the autoconf list,
and there is where I assume that suggestions and comments should be
directed.
-
My original posts:
http://mail.gnu.org/pipermail/autoconf/2002-October/014384.html
http://mail.gnu.org/pipermail/autoconf/2002-October/014387.html
--
{+} Jeff Squyres
{+} [EMAIL PROTECTED]
{+} Research Associate, Open Systems Lab, Indiana University
{+} http://www.osl.iu.edu/
configurations and "ways of doing things" out there, many of
which will necessarily be totally different from each other. In my
organization, the IT support staff is responsible for *all* software exept
that which is being developed. I can't change that.
--
{+} Jeff Squyres
{+} [EM
ation. This is actually the central issue.
I made the above remark because someone made the suggestion / implication
that all of my developers could each have their own installation, and that
would avoid the "central IT support" problem.
--
{+} Jeff Squyres
{+} [EMAIL PROTECTED]
{+} Rese
you could certainly *benefit* from them, even if you do not *need*
them).
--
{+} Jeff Squyres
{+} [EMAIL PROTECTED]
{+} Research Associate, Open Systems Lab, Indiana University
{+} http://www.osl.iu.edu/
23 matches
Mail list logo
