Re: How to optionally test for a C++ compiler?

* Ossama Othman: > Something like the following should be a good smoke test: > > class Foo > { >public: > Foo (void) : bar_ (0) { } > virtual ~Foo (void) { } > virtual int bar (void) { return this->bar_; } >private: > int bar_; > }; > > int main (int, char *[]

vs "config.h"?

Hi, this is probably a silly questions, but I'll take my chance: I was wondering if there's a preferred way to include the config.h file generated by autoconf (with the define settings)? I.e. is there any reason why #include would be better than #include "config.h" (or vice versa) for the "g

Re: Build single library from multiple source directories

Erik de Castro Lopo <[EMAIL PROTECTED]> writes: > Hi all, > > I'm trying to build a single library from multiple source > directories without much luck. Does anybody have any clues > on how this may be done? Maybe a package that does this? We do this for Coin: http://www.coin3d.org>. Regards,

Re: Standard macro for OpenGL check?

the Mesa libraries, we will also set $sim_ac_gl_is_mesa to dnl "yes". dnl dnl dnl Author: Morten Eriksen, <[EMAIL PROTECTED]>. dnl dnl TODO: dnl* [mortene:2122] make sure this work on MSWin (with dnl Cygwin installation) dnl AC_DEFUN(SIM_CHECK_OPENGL,[ dnl Autoconf is

Re: Standard macro for OpenGL check?

"Braden N. McDaniel" <[EMAIL PROTECTED]> writes: > Suppose I've got a library and I want to install an autoconf macro > on the user's system so that if the user is developing a library > dependent on mine, s/he can use this macro to check for the presence > of my library. [snip] One way to solve

Re: Standard macro for OpenGL check?

Akim Demaille <[EMAIL PROTECTED]> writes: > | AC_DEFUN(SIM_CHECK_OPENGL,[ > | dnl Autoconf is a developer tool, so don't bother to support older versions. > | AC_PREREQ([2.14.1]) > > Please, don't depend on this, it does not exist. Guys, get your ass in gear and release a new version of Autoco

Re: Standard macro for OpenGL check?

"Braden N. McDaniel" <[EMAIL PROTECTED]> writes: > Might there be any interest in having a standard macro to check for > OpenGL packaged with autoconf? There's already such a thing for X; > so I wonder, how about OpenGL? Sounds like a good idea to me, as OpenGL is getting to be a pretty common l

[PATCH] miniscule documentation fix

An example from the AC_HELP_STRING doc was missing a parenthesis. Regards, Morten Eriksen Index: autoconf.texi === RCS file: /cvs/autoconf/doc/autoconf.texi,v retrieving revision 1.247 diff -u -r1.247 autoconf.texi

[PATCH] X11 linking

nst current CVS head branch attached below. (Note: the patch hasn't been tested, as I'm running an older Autoconf at the moment, due to the mismatch with the current CVS Automake.) Mon May 29 15:35:51 2000 Morten Eriksen <[EMAIL PROTECTED]> * acspecific.m4: Fix the fi

Re: configure.in in subdirectories

Diego Sevilla Ruiz <[EMAIL PROTECTED]> writes: > [...] AC_CONFIG_SUBDIRS [...] does automake support this macro and > descend to the subdirectories to build Makefile.in, etc? No. > (and autoconf for generating its corresonding subdir/configure? No. > or must I do it myself? Yes. If you know

Re: AC_CHECK_LIB and C++

Bram Stolk <[EMAIL PROTECTED]> writes: > I want to check for simple global C++ func. However, even if I set > the language to C++, the conftest.C is created in such a way, that > the func I am looking for is prototyped in "extern C", thereby > causing the check to fail. You're probably running

Bugfix for _AC_OBJEXT

XT macro -- the value of $ac_exeext is explicitly set to .exe if CYGWIN, MINGW32 or EMXOS2 is detected. As I said, a hornet's nest. Was anyone on the list aware of these bugs? Regards, Morten ========= 2000-08-30 Morten Eriksen <[EMA

Re: C++ Shared Libraries

Robert Boehne <[EMAIL PROTECTED]> writes: > From what I have read about libtool it cannot handle C++ shared > libs. [...] Well, it works for us (http://www.coin3d.org) with a number of large and complex C++ libraries. (We're using Libtool v1.3.5, BTW.) > Is there any work going on in this area,

Re: Bugfix for _AC_OBJEXT

rticular, it looks hard to do the necessary changes without breaking the newly introduced AC_NO_EXECUTABLES hack. So I'm afraid I'll leave that mess alone for now. :^/ Regards, Morten 2000-08-30 Morten Eriksen <[EMAIL PROTECTED]> * acspecific.m4: _AC_OBJEXT was using

Re: Bugfix for _AC_OBJEXT

"Lars J. Aas" <[EMAIL PROTECTED]> writes: > Actually, it doesn't. Many of the initial configure tests fail on > Cygwin because of this mess, I seem to recall. None of the important ones, I believe (my patch fixes the only case I could find). There are some ugly hacks in Autoconf to take specia

Should the C++ sourcefile extension be changed?

ff -u -r1.854 ChangeLog --- ChangeLog 2000/09/12 10:23:08 1.854 +++ ChangeLog 2000/09/12 11:05:50 @@ -1,3 +1,9 @@ +2000-09-12 Morten Eriksen <[EMAIL PROTECTED]> + + * aclang.m4 (AC_LANG(C++)): Use .cxx instead of .cc as + extension for C++, to please more compilers

Serious problem with Autoconf on RedHat 7

Hi, I just discovered a nasty problem with the latest CVS Autoconf on Red Hat Linux v7 (default setup, i.e. with g++ 2.96). In short, the AC_TRY_COMPILE in the configure.in script below will fail: ->8-->8--->8-->8--->8-->8--->8-->8--->8-->8--->8-->8--->8-->8-- AC_INIT(configure.in) AC_LANG_CPLU

[PATCH] Serious problem with Autoconf on RedHat 7

Hi, I don't know if this mail got through without losing a few electrons due to the recent mailinglist hickups, so I'm resending it. With a patch this time, so it might be easier to get it applied. :^} 2000-10-02 Morten Eriksen <[EMAIL PROTECTED]> * aclang.m4 (

Re: [PATCH] Serious problem with Autoconf on RedHat 7

Akim Demaille <[EMAIL PROTECTED]> writes: > | Index: aclang.m4 > | === > | RCS file: /cvs/autoconf/aclang.m4,v > | retrieving revision 1.68 > | diff -u -r1.68 aclang.m4 > | --- aclang.m4 2000/10/02 13:11:28 1.68 > | +++ acl

AC_PROG_CC not working

Hi, I don't see the expected behavior from the AC_PROG_CC macro. This configure.in file: -->8>8>8>8>8>8>8>8>8-- AC_INIT(configure.in) AC_PROG_CC(foo bar supercompiler) AC_OUTPUT() -->8>8>8>8>8>8>8>8>8-- ..will generate this outpu

Re: AC_PROG_CC not working

Akim Demaille <[EMAIL PROTECTED]> writes: > Really, giving a list of compilers seems bad to me. It should be > the same list for everybody, i.e., let's fix the Autoconf builtin > list if its wrong, but let's not go for various flavors of > configure. A few days ago I would have agreed with you

Re: AC_PROG_CC not working

Akim Demaille <[EMAIL PROTECTED]> writes: > So I am back to something I raised some time ago: why the heck do we > have to compile to recognize Mingw etc.? Can't we just uname? I'll second that notion. :^) One argument for using the output of uname in some form instead of the current scheme is

[PATCH] A better (?) _AC_EXEEXT

Index: ChangeLog === RCS file: /cvs/autoconf/ChangeLog,v retrieving revision 1.897 diff -u -r1.897 ChangeLog --- ChangeLog 2000/10/05 13:52:41 1.897 +++ ChangeLog 2000/10/10 16:29:34 @@ -1,3 +1,9 @@ +2000-10-10 Morten Eriks

Re: [PATCH] A better (?) _AC_EXEEXT

* Morten | It was also mentioned on the list a while ago (by yours truly) how the | _AC_EXEEXT macro has a circular dependency: _AC_EXEEXT uses | AC_LINK_IFELSE which uses $ac_exeext which is found by _AC_EXEEXT. * Akim | AFAICS you still have this problem: you use AC_LINK_IFELSE. You | shouldn'

[PATCH] A better _AC_EXEEXT, Take II

.897 diff -u -r1.897 ChangeLog --- ChangeLog 2000/10/05 13:52:41 1.897 +++ ChangeLog 2000/10/11 09:28:11 @@ -1,3 +1,9 @@ +2000-10-10 Morten Eriksen <[EMAIL PROTECTED]> + + * acspecific.m4 (_AC_EXEEXT): Change of strategy for the macro, we + now search for a valid executabl

[PATCH] Misc fixes for use of extension suffices

diff -u -r1.897 ChangeLog --- ChangeLog 2000/10/05 13:52:41 1.897 +++ ChangeLog 2000/10/11 10:05:54 @@ -1,3 +1,10 @@ +2000-10-11 Morten Eriksen <[EMAIL PROTECTED]> + + * acgeneral.m4 (AC_RUN_IFELSE): Add missing executable suffix. + * aclang.m4 (_AC_LANG_COMPILER_WORKS): Li

Re: [PATCH] A better (?) _AC_EXEEXT

Log --- ChangeLog 2000/10/05 13:52:41 1.897 +++ ChangeLog 2000/10/11 10:42:34 @@ -1,3 +1,9 @@ +2000-10-11 Morten Eriksen <[EMAIL PROTECTED]> + + * acspesific.m4 (_AC_CYGWIN, _AC_MINGW32): Avoid false negatives + when using compilers which do not set up special defines on th

Re: [PATCH] A better (?) _AC_EXEEXT

* Akim | Then let me restate my question: why don't you use AC_TRY_EVAL just | like in AC_EXEXT: this is a good first step I think. Umm.. I assume you mean to ask "why not use AC_TRY_EVAL in AC_EXEEXT just like in AC_OBJEXT" (and not "..like in AC_EXEEXT")? If so, my question for you is then: wh

Re: [PATCH] A better (?) _AC_EXEEXT

: ChangeLog === RCS file: /cvs/autoconf/ChangeLog,v retrieving revision 1.897 diff -u -r1.897 ChangeLog --- ChangeLog 2000/10/05 13:52:41 1.897 +++ ChangeLog 2000/10/11 09:28:11 @@ -1,3 +1,9 @@ +2000-10-11 Morten Eriksen <[EM

Re: AC_PROG_CC not working

Peter Eisentraut <[EMAIL PROTECTED]> writes: > [...] I mean if you do cc conftest.c -o conftest, and afterwards > there is no file "conftest", but there is a file "conftest.exe" that > wasn't there before, that should be pretty conclusive, no? Not really, no. For instance, Cygwin does this funny

Re: AC_PROG_CC not working

* Pavel Roskin | Since EXEEXT="" makes "cp" fail it's not a good choice. So instead | of doing "test contest -ef contest.exe" do "cp contest contest.ac_" | and reverse the logic (i.e. if "cp" fails we use ".exe") Well, I don't think this is such a good idea. What if the Cygwin port of ``cp'' is s

Bug: explicitly setting CC made defunct

Hi, a bug has been introduced by one of the commits from the last day or so. Upon this configure.in file AC_INIT(configure.in) AC_PROG_CC autoconf (fresh from the head CVS) generates a configure script which produces this output when run as "./configure CC=foobar" checking for gcc... no

Re: Bug: explicitly setting CC made defunct

Akim Demaille <[EMAIL PROTECTED]> writes: > Thanks, I'm sure I'm responsible for this. Most certainly my recent > changes involving AC_CHECK_TOOLS. I'm on it. Don't bother, I nailed it down. Patch coming up. Morten

Re: Bug: explicitly setting CC made defunct

Akim Demaille <[EMAIL PROTECTED]> writes: > >>>>> "Morten" == Morten Eriksen <[EMAIL PROTECTED]> writes: > > Morten> Hi, a bug has been introduced by one of the commits from the > Morten> last day or so. Upon this configure.in file >

Re: Bug: explicitly setting CC made defunct

Akim Demaille <[EMAIL PROTECTED]> writes: > | 2000-10-17 Morten Eriksen <[EMAIL PROTECTED]> > | > | * acgeneral.m4 (AC_CHECK_TOOL[S]?): As AC_CHECK_PROG[S]? first > | tests the value of the VARIABLE argument when looking for > | executables

Re: Where did the Cygwin and Mingw checks go?

* Mo DeJong > I was under the impression that autoconf would just try to compile > conftest.c and then find the obj extension by looking for files > named conftest.*, filtering out conftest.c and then using whatever > was left (either conftest.o or conftest.obj). That might have > changed, but it

[BUG] AC_PATH_XTRA

Hi, given this configure.in (a useless case, but it'll serve as an example): == [snip] AC_INIT(configure.in) AC_CONFIG_HEADER(config.h) if false; then AC_PATH_XTRA else AC_PATH_XTRA fi AC_OUTPUT == [snip] ..the r

Re: Where did the Cygwin and Mingw checks go?

Paul Berrevoets <[EMAIL PROTECTED]> writes: > [...] for AC_EXEEXT please take into consideration that on UWIN > (which uses a cc wrapper for MSVC), the compiler also generates a > .pdb file, which if you don't filter it out along with .obj, would > be used as the extension for executables. I've

Re: AC_OBJEXT again

Akim Demaille <[EMAIL PROTECTED]> writes: > OBJEXT and EXEEXT [...] define precisely what they are (build, or > host?), [...] Just wanted to add my 0.02 Kroner: after pondering this issue for a while, I tend to believe we should first and foremost view them as characteristics of the _compiler_ -

Re: Release next week?

Akim Demaille <[EMAIL PROTECTED]> writes: [About changing language for a future Autoconf rewrite] > No really, I think Perl is the most serious candidate. Check out this snippet from Automake's TODO file: rewrite in guile (RMS request) at the same time, consider adding a GUI