similar to: [LLVMdev] Re: [llvm-commits] CVS: */Makefile.am

Reid Spencer wrote: > On Sun, 2004-10-10, Misha Brukman asked "Why can't we use wildcards > instead of listing all the sources" and then wrote in response to my > reply: > >>On Sun, Oct 10, 2004 at 04:40:48PM -0700, Reid Spencer wrote: >> >>>http://www.gnu.org/software/automake/manual/html_mono/automake.html#wildcards >>> >>>is your

John, The point I was trying to make (and obviously didn't) was that because automake can make the mechanics of building/testing/packaging a release so much easier (one command), it is possible for this to be automated regularly (e.g. nightly test). Consequently, the problems only seen when building a distribution would be available much sooner than the week before the release. Distribution

On Mon, Nov 10, 2003 at 03:31:34PM +0100, gtgbr@gmx.net wrote: [re: http://xiph.org/archives/cvs/4109.html] > I have only automake 1.7.8 installed and the check complains that it > can't find 1.6.x and bails out. My previous makes worked fine with 1.7.x > ... is it possible to improve this so it works with "or later"? I'd like to, but haven't been able to come up

the attached patch against current svn brings autogen.sh in line with that in ogg/, and updates Makefile.am appropriately. (needed to build on os x and probably elsewhere) Conrad. -------------- next part -------------- Index: Makefile.am =================================================================== --- Makefile.am (revision 6517) +++ Makefile.am (working copy) @@ -1,6 +1,6 @@ ## Process

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

If you rebuild the Makefiles using automake >= 1.13 then you'll likely hit this error: Makefile:1904: *** unterminated variable reference. Stop. This is caused by automake miscompiling GNU make macros that appear in the 'TESTS' variable decl in 'ocaml/Makefile.am'. I posted a bug about this upstream. It hasn't appeared yet, but it should turn up here in the near

On Mon, 11 Oct 2004, John Criswell wrote: > I believe the two best things that we can do to shorten releases is the > following: > > 1. Re-arrange the LLVM and LLVM-GCC builds to build in one fell swoop. > I checkout out, I type make, and it all builds. This requires moving > parts of llvm/runtime into llvm-gcc, or making llvm-gcc an LLVM project, > or some other approach.

Folks, I have completed the addition of automake makefiles to LLVM. All libraries, tools, and runtime libs build now with automake. Note that there are still many missing things in the automake support. Right now it just builds the basic software. However, before I invest more time in it, I thought some comparison would help us make some decisions about whether or not to proceed with automake

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),

Christian Weisgerber <naddy@mips.inka.de> wrote: > | # nasm build rule: > | %.lo: %.s Even with gmake, this really works only by accident. Automake generates a competing suffix rule, and gmake apparently gives the rule above a higher priority than the suffix rule (or that just happens to be the evaluation order). Matt, since you seem to understand automake, can you come up with

One more update. The Makefile.am for analyze was wrong. It wasn't linking in the some of the passes. The new size is 56951088 which is in line with the other executables. Also, I have now completed a run of projects/llvm-test/MultiSource with the tools generated by automake. The only errors were for: TEST (llc) 'sgefa' FAILED! TEST (jit) 'sgefa' FAILED! TEST (jit)

Without "no-dependencies" in every single Makefile.am's AUTOMAKE_OPTIONS line, automake will put gnu-specific instructions that will barf a) if you don't use gmake, and b) don't use gcc. This is actually in the automake manual, section 7.11, page 26 -- it's not an unexpected thing: "Currently, this support [automatic dependency generation] requires

I just noticed this warning from the autoreconf portion of the buildbot log: autoreconf: running: automake --no-force include/Makefile.am:9: shell unset LANG && svnversion -n $(top_srcdir: non-POSIX variable name include/Makefile.am:9: (probably a GNU make extension) include/Makefile.am:10: shell if test "$(SVNREV: non-POSIX variable name include/Makefile.am:10: (probably a GNU make

can anyone enlighten me how to make icecast2's autogen.sh work under freebsd 5.1? > Checking for automake version > > You must have automake version 1.6 installed > to compile ices. > Download the appropriate package for your distribution, > or get the source tarball at ftp://ftp.gnu.org/pub/gnu/ i have /usr/local/bin/automake (1.5) and /usr/local/bin/automake17 installed

Hello All: I just checked out the whole icecast but cannot build anything because autogen wouldn't cooperate. I have automake-1.7.6 just installed from ftp.gnu.org. Below is an example output in trying to build "icecast"; it's not very short... Thanks in advance for any help. --- $~/icecast/icecast> ./autogen.sh Checking for automake version found automake found

> > > $ aclocal && autoconf && automake -c -a -i > > > aclocal: configure.in: 45: macro `AM_PATH_XMMS' not found in > library > > > > my hunch is that your version of either automake or possibly > > autoconf is not recent enough. > > No. He simply doesn't have xmms installed. That's what I mentioned > a while ago:

On Mar 2, 2015, at 12:49 PM, Rob Groner <rgroner at RTD.com> wrote: > Well, having spent a decent amount of time trying to get my driver file added into the Makefile build system (and failing), I've decided that for now, simply adding that one line to the openups-hid.c file and recompiling is the best route to go. When I can no longer live with the limited nature of the openups-hid

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.

On Wednesday 20 October 2004 12:01, Reid Spencer wrote: > 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. I might just here to

Because this 'feature' is broken (since 2013): https://debbugs.gnu.org/cgi/bugreport.cgi?bug=13928 we have to replace all instances of $(top_srcdir) in *_SOURCES lines with a relative path. According to what I read, this shouldn't break split builds, but I didn't test it. The only things automake moans about now are: * Unescaped left brace in regex is deprecated, passed