use of .c.cc suffix rule in making bin_PROGRAMS

I'm running autoconf-2.53, automake-1.6.2, and libtool-1.4d. If I have a source, x.c, the following automake snippet will not work (it invokes gcc on x.c, instead of g++ on x.cc; and the .deps/x.Po file contains just #dummy) bin_PROGRAMS = x x_SOURCES = x.cc .c.cc: $(LN_S) $< $@ But

Re: question about -rpath

package I'm building, but there is no libtips.so) The autotools documentation doesn't seem to explain anywhere what is going on. Or does it? Thanks again, - Ted Ted Irons wrote: > Starting with > > [187.virgo.image_wish] make image_sh > /bin/sh ../../libtool --mode=li

install-includeHEADERS

The way that C++ include files are currently installed can trigger a multitude of expensive recompilations (esp. if the include files contain templates). To change the way that C++ include files are installed I am currently using @INSTALL_HEADERS@ in the Makefile.am's and using INSTALL_HEA

Re: automake parallel install

Just a thought ... Keep different versions of the autotools (autoconf, automake, and libtool) in different autoconf directories (for eg, autoconf-2.52, automake-1.5b, and libtool-1.4d could be installed in /local/autoconf-2.52). In addition, each package has its own bootstrap script that invokes

Re: building same source with different flag

with -c and -o, and that passes. I have no idea why the configure check is using CFLAGS instead of CXXFLAGS. I changed the CXXFLAGS in ACX_CXXCOMPILE to AM_CXXFLAGS, but that made no difference. Thanks again for your help, - Ted Alexandre Duret-Lutz wrote: > Ted Irons <[EMAIL PROTEC

Re: building same source with different flag

My first post involved using automake-1.5b. I have subsequently tried the same thing using automake-1.5. The error message was the same. - Ted P.S. Automake-1.5b seems to exhibit other peculiarities - like picking up shared libraries from the wrong place. When I get back to automake-1.5b, I'll

Re: building same source with different flags

I appreciate the reply but my original email had a typo: automake-1.4b should read automake-1.5b. I didn't try this with automake-1.5. - Ted Ted Irons wrote: > Am using autoconf-2.5.2, automake-1.4b, libtool-1.4b > This should read automake-1.5b. > on an ix86 box run runn

building same source with different flags

Am using autoconf-2.5.2, automake-1.4b, libtool-1.4b on an ix86 box run running Suse Linux with kernel-2.4.6. My Makefile.am contains the following snippets: libhrnet_la_SOURCES = \ ascbin.cc \ allocate.cc \ fileio.cc \ forward.cc \ initall.

Re: install-data-hook

I see that I was confusing local rules and hooks. What I need is install-data-hook and not install-data-local. Sorry for the noise, - Ted --- Begin Message --- It is my understanding (from reading the info pages) that the install-data-hook target is done after the install-data target.

install-data-hook

It is my understanding (from reading the info pages) that the install-data-hook target is done after the install-data target. But I have a Makefile.am that has pkgdata_DATA = ${FILES} install-data-local: cmd1 cmd2 The corresponding Makefile has the following target:

AC_PATH_X

On a Linux-2.4 machine using the following AC_PATH_X AC_LANG_PUSH(C) AC_CHECK_LIB(Xmu, XmuLookupStandardColormap,,, -lXt -lX11) AC_CHECK_LIB(X11, XCreateWindow) AC_LANG_POP(C) I get checking for X... libraries /usr/X11/lib, headers checking for XmuLookupStandardColormap in -lXmu... no

multi-language-branch of libtool

Does the multi-language-branch of libtool work with autoconf-2.13 and automake-1.4? Thanks, - Ted