similar to: New automake targets and Debian packages

Could someone please check and see what I am doing wrong with automake in branches/AsciiDoc? http://boxster.ghz.cc/projects/nut/browser/branches/AsciiDoc/docs/Makefile.am?rev=1917 The problem is that 'make html' never recurses into docs/website. I have listed 'website' in the 'SUBDIRS' section of docs/Makefile.am, and 'docs/website/Makefile' is listed in the

Dear NUT developers, I have converted NUT's build system to Automake/Libtool. Right now, the new build system is contained in the "automake" branch, at: ssh://svn.debian.org/svn/nut/branches/automake I plan to merge this into the main branch after a period of testing, if there are no objections. Here are some highlights: * automatic dependency tracking: no more need to do this

Seems to be broken in the current SVN: [...] x86_64-linux-gnu-gcc -I../include -DDBUS_API_SUBJECT_TO_CHANGE -I/usr/include/hal -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -DINET6 -O2 -D_REENTRANT -DNETSNMP_USE_INLINE -Wall -Dlinux -I. -I/usr/include -O2 -Wall -Wsign-compare -s -o energizerups energizerups.o ../common/upsconf.o ../common/parseconf.o ../common/state.o main.o dstate.o

Hallo. Here is a simplification of the automake stuff for nut 2.2.2. The idea is simple: libcommon.a contains stuff for the binaries libparseconf.la contains stuff for binaries and shared library Both are NOINST, automake understands perfectly our intentions. The rest is only a removal of the implicitly defined stuff. On top of the parallel build patch I got build success on all platforms

Hello, I am writing you about the GNU R-Project, as part of by effort to help GNU projects provide a better, more consistent build system. Currently, your project does not support the DESTDIR variable in generated Makefiles (marked as optional in the GNU coding policies, make and automake manual). In my opinion, DESTDIR support can be very helpful for the user, the distribution-specific

--- builder/Makefile.am | 18 +++++++++++++- configure.ac | 2 ++ mllib/Makefile.am | 60 +++++++++++++++++++++++++++++++--------------- ocaml/Makefile.am | 28 +++++++++++++++------- ocaml/examples/Makefile.am | 13 ++++++++++ resize/Makefile.am | 18 +++++++++++++- sparsify/Makefile.am | 18 +++++++++++++- sysprep/Makefile.am | 18

Hi, I'm trying to compile icecast-kh (last version) on a OpenBSD machine. While I execute ./autogen.sh an error occurs: autoheader libtoolize --automake automake --add-missing automake: #################### automake: ## Internal Error ## automake: #################### automake: unrequested trace `include' automake: Please contact <bug-automake@gnu.org>. at

I have the latest updates to CentOS 5.6. However, I need different versions of autoconf and automake. How can this be handled? What will happen on later updates? Currently I have autoconf (GNU Autoconf) 2.59 automake (GNU automake) 1.9.6 I need autoconf 2.69-1 and automake 1.11.6. Thanks, John -- John J. Boyer; President, Chief Software Developer Abilitiessoft, Inc.

Josh, Automake 1.10 on OSX is giving me warnings like the following: test/Makefile.am:50: wildcard *.raw: non-POSIX variable name test/Makefile.am:50: (probably a GNU make extension) test/Makefile.am:50: wildcard *.flac: non-POSIX variable name test/Makefile.am:50: (probably a GNU make extension) test/Makefile.am:50: wildcard *.oga: non-POSIX variable name

Hello, I've tried NUT trunk SVN branch some time ago in order to use it with a Blazer USB UPS (megatec protocol driver supported by Carlos Rodriguez). This UPS wasn't yet supported by NUT but I was able to compile and test the software on my Debian. I download in order to try latest Rev: 805 today to see if USB support for my UPS where better but the 'autoreconf' command give me

Hallo, trying to compile the current 1.1 git snapshot under Debian Wheezy gives me: configure.ac:7: option `info-in-builddir' not recognized autoreconf: automake failed with exit status: 1 Do I now need a specific newer version of automake? Seems to be the result of commit 13f9bc1ff199bea46 "Add support for out-of-tree ("VPATH") builds." Undoing the change to

Rather than always trying to install ocaml files into $(OCAMLLIBS), which is likely to be root-owned and therefore fail during a './configure --prefix=$HOME/subdir', we instead choose to always install relative to $(prefix) and let distro packagers take steps post-install to move the distro's pre-built copy into the correct location for the distro. This fixes a 'make

Compiling current git on MacOSX 10.5.8 Darwin mac.stare.cz 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386 $ ./autogen.sh Updating build configuration files for FLAC, please wait.... configure.ac:26: require Automake 1.11, but have 1.10 autoreconf: automake failed with exit status: 1 Why

All, we recently had a user report an issue associated with utilizing LLVM-MC as the desired assembler in place of GNU’s GAS. They are utilizing a tangled mess of automake scripts to build this respective software package and have decided to manually override the “CCAS” macro to point directly to LLVM-MC (rather than using Clang). Apparently, automake assumes that whatever “compiler” (as it is

I make changes in open source tree to implement autoconf/automake. What's new ? - new acinclude.m4 ( based on old aclocal.m4 + new macros OSSH_EXPAND_PATHS and OSSH_SHOW_OPTIONS - new configure option --with-askpass=PATH - updated acconfig.h ( based on old acconfig.h with removed USE_EXTERNAL_ASKPASS and new ASKPASS_PATH + new config.h.top and config.h.bot ) !!! in this file has two lines

I've eagerly grabbed the current CVS as of a few minutes ago, and attempted to build and play with theora, but am running into a snag with the autogen.sh script: ------------------------------------------------------------------------ bash-2.05# ./autogen.sh I am going to run ./configure with no arguments - if you wish to pass any to it, please specify them on the ./autogen.sh command line.

Hello, I'm using autotools to build my little lang. So I want to have something like this in my Makefile.am: mylang_SOURCES = mylang.cpp mylang_LDADD = mylib.a `llvm-config --cppflags --ldflags --libs core jit native ipo` But automake complains: tools/Makefile.am:8: linker flags such as `--cppflags' belong in `mylang_LDFLAGS I tried different workarounds but nothing helps :( The only

I'm re-thinking my penchant for automake. automake is great for many standard applications that just need to get portable makefiles up and running quickly. However, it turns out that LLVM is "different enough" from a standard application that automake might not be the best choice. Here's some of the problems I've run into: 1. There's no way to tell automake to build

RHEL 6 has automake 1.13.4. Since we have stopped supporting RHEL 5, there is no need for the complex macro to check for older versions of automake that didn't have 'serial_tests'. --- configure.ac | 17 +---------------- 1 file changed, 1 insertion(+), 16 deletions(-) diff --git a/configure.ac b/configure.ac index 88f5568..9fde5c5 100644 --- a/configure.ac +++ b/configure.ac @@

After puzzling about the size of the executables and the build times, I discovered (thanks Chris!) that I had compiled everything without debug symbols in the automake version. So, here's some revision from the first version of this email. The build times didn't change much (I guess I/O is cheap on my machine). The new "Build With Automake" times are 20m28.672s (elapsed),