autoreconf/automake w/out autoheader

How does one go about using the AC_CONFIG_HEADERS functionality without autoreconf and automake invoking autoheader? I've been letting autoheader generate an unused 'config.h'. For example: AC_CONFIG_HEADERS([config.h iBase_FCDefs.h]) Is there a less klugey way to do this? thanks, - jason

options and automake version

are not essential to the build process. Unfortunately, automake fails when it encounters unrecognized options. Is there some trick I could use to conditionally add the options if they are supported? thanks, - jason kraftcheck

running tests in parallel

It would be nice if it were possible to run tests in parallel using automake. Waiting for tests to complete on a 4-way box while they are run on a single CPU is annoying. As most 'make' implementations already support running in parallel (-j), automake could just utilize this functionality to

generated headers

I have some headers that are generated from other files. I don't what these headers installed nor included in the dist. I do need them for the compilation of some object files, though. If I attempt to add explicit dependencies such as: MeshTSTT.lo: $(TSTT_HDRS) then automake will not generate

Re: yet another patch to reduce make output

Ralf Wildenhues wrote: Hello Jason, thanks for your work. While I'm not to judge this, and pretty indifferent about it, a couple of question to clarify a bit: * Jason Kraftcheck wrote on Thu, Jan 18, 2007 at 11:36:55PM CET: This patch prefixes the compile and link commands

yet another patch to reduce make output

I know there's been patches in the past to reduce the output of the makefiles generated by automake that have not been accepted. I understand that the main reasons for opposing such a patch are: a) hiding output might result in more incorrect or uninformative bug reports b) it is more bloat in

Re: verbosity

Ralf Wildenhues wrote: * Christopher Sean Morrison wrote on Mon, Jan 15, 2007 at 07:55:27PM CET: Counterproductive presumptuous flamings aside, there are compelling arguments on both sides of the issue for having or quelling verbose compilation output. Yes, the flaming all helps nothing

enable dependency tracking whenever available

Is there a way to enable dependency tracking by default even if only slow mechanisms are available (as if --enable-dependency-tracking were always specified?). thanks, - jason

Re: enable dependency tracking whenever available

Ralf Wildenhues wrote: Hello Jason, * Jason Kraftcheck wrote on Thu, Jan 18, 2007 at 07:39:30PM CET: Is there a way to enable dependency tracking by default even if only slow mechanisms are available (as if --enable-dependency-tracking were always specified?). You mean as the package

Re: verbosity

Ralf Wildenhues wrote: * Jason Kraftcheck wrote on Thu, Jan 18, 2007 at 07:10:19PM CET: Ralf Wildenhues wrote: http://lists.gnu.org/archive/html/automake-patches/2006-08/msg00024.html I don't understand why this is such a controversial issue. Then - you must not have had to deal

verbosity

Hi, I'm working on moving an existing project to use autotools. One of the issues that I've encountered is that the build process is very verbose. Due to factors outside my control, the CPPFLAGS used for compiling contain a very long list of include flags. This results in the compile command

building a shared library that depends on a static library

Automake includes the contents of the $LIBS variable in all link commands, including linking libraries. This results in the following behavior: 1) If libtool is creating a static library, this seems to work fine. The libraries in $LIBS are listed as dependencies in the resulting .la file. 2)

Re: building a shared library that depends on a static library

Ralf Wildenhues wrote: Hi Jason, * Jason Kraftcheck wrote on Tue, Feb 28, 2006 at 02:42:34AM CET: Automake includes the contents of the $LIBS variable in all link commands, including linking libraries. This results in the following behavior: 3) If libtool is creating a shared library

automake missing subdirs

I am working on the development of a set of libraries. The core of the code is LGPL, but it includes several optional modules that require proprietary libraries. The problem with the modules using proprietary libraries is that the company that owns those libraries requies a license agreement