Re: PATCH: Fix dependency tracking (revised)

Tom Tromey wrote: > > >>>>> "Robert" == Robert Boehne <[EMAIL PROTECTED]> writes: > > Robert> 2001-04-25 Robert Boehne <[EMAIL PROTECTED]> > Robert> * configure.in: Add _am_dep_true='@AMDEP_TRUE@' and AC_SUBS

@_am_quote@ not replaced by 'configure'

ke libtool, etc. would help find these problems before they get checked in. The test could simply be skipped if there is no C/C++/F77/? compiler found. I would be more than happy to contribute the test as well. Any thoughts? Robert -- Robert Boehne Software Engineer Ricardo Sof

patch: missing uninstall-am target breaks non-gnu make

This is just a patch for the fix suggested to me. Rob openbsduninstall.patch

distdir target

A question: the first few lines of the distdir target (using --foreign are) distdir: $(DISTFILES) @for file in $(DISTFILES); do \ d=$(srcdir); \ dir=`echo "$$file" | sed -e 's,/[^/]*$$,,'`; \ however, the --cygnus option creates distdir: $(DISTFILES) @for fi

Re: distdir target

- Original Message - From: "Tom Tromey" <[EMAIL PROTECTED]> > >>>>> "Robert" == Robert Collins <[EMAIL PROTECTED]> writes: > > Robert> however, the --cygnus option creates > > Robert> distdir: $(DISTFILES) > Robert&

RE: pr19.test

I recall it failing on openBSD 2.8. Rob

Re: pr19.test

I went to retest this : I couldn't find pr19.test. pr9, yes, pr19, no. Is it still in HEAD? Rob - Original Message - From: "Tom Tromey" <[EMAIL PROTECTED]> To: "Robert Collins" <[EMAIL PROTECTED]> Cc: "edward" <[EMAIL PROTECTED]>; &

Re: Auto-tools & Win32 & Borland C++ Builder

er seen a patch rejected because it wasn't for gcc, I think everyone's goal is to have a set of tools that work everywhere for every situation. Currently these tools will do the job for 95% of projects on 95% of platforms (or better) and there is nothing else that can claim that. << END_FLAME Cheers! Robert -- Robert Boehne Software Engineer Ricardo Software Chicago Technical Center TEL: (630)789-0003 x. 238 FAX: (630)789-0127 email: [EMAIL PROTECTED]

[PATCH] fix install on cygwin with shared libraries

There is a current problem with automake and libtool on cygwin when shared libraries are enabled. The problem is in two parts. The root cause of the problem is that the wrapper script for relinking binaries linked with .dll's when they are run from the build directory, cannot have a .exe extensio

Re: cygwin libtool breakage

- Original Message - From: "Robert Collins" <[EMAIL PROTECTED]> > > - Original Message - > From: "Gary V. Vaughan" <[EMAIL PROTECTED]> > To: "Robert Collins" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Sent:

auto generate -DLIBfoo_COMPILATION for libtool libraries

The attached patch auto defines -DLIBfoo_COMPILATION in the _CFLAGS variable for libtool libraries. This is a proof of concept patch only, it's probably the wrong way to do it, there may be issues with always adding the define even if there are userland defines present. Consider this a request-to

DEPDIR not set by current CVS Automake

this is a bug as it worked in previous versions of Automake. Thanks, Robert -- Robert Boehne Software Engineer Ricardo Software Chicago Technical Center TEL: (630)789-0003 x. 238 FAX: (630)789-0127 email: [EMAIL PROTECTED]

Re: Automake 1.5 - depcomp not added to DIST_COMMON

- Original Message - From: "Raja R Harinath" <[EMAIL PROTECTED]> > > This doesn't look like it'll work with, say > > automake --add-missing src/Makefile > > This won't add 'depcomp' to DIST_COMMON in the top Makefile.in. You cannot use automake --add-missing src/Makefile until a strai

RE: Bugs/Features in handling of continued Makefile rules

> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > > 3. Because of a stupidity in Tru64 make, automake displays >an error message if comments are found immediately after > the tab (plus >zero/more whitespace). I think perhaps a nicer approach > would

Re: Bugs/Features in handling of continued Makefile rules

- Original Message - From: "Dean Povey" <[EMAIL PROTECTED]> Subject: Re: Bugs/Features in handling of continued Makefile rules > >> -Original Message- > >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > >> > >> > > > >Use > >## Comment > >They get omitted from Makefile.in.

Re: Bugs/Features in handling of continued Makefile rules

- Original Message - From: "Raja R Harinath" <[EMAIL PROTECTED]> > Hi, > > "Robert Collins" <[EMAIL PROTECTED]> writes: > > - Original Message - > > From: "Dean Povey" <[EMAIL PROTECTED]> > > Subjec

RE: [patch]: automatically buiding rpm (and others) with automake

> -Original Message- > From: Christophe Tronche [mailto:[EMAIL PROTECTED]] > Sent: Monday, November 05, 2001 6:26 AM > > autopack also has very definitive ideas on how to build a package from > the source distribution. It does so by performing > > ./configure --prefix= > make > mak

RE: Makefile.in files

> -Original Message- > From: Fausto Sanchez [mailto:[EMAIL PROTECTED]] > Sent: Thursday, November 08, 2001 3:51 PM > To: [EMAIL PROTECTED] > Subject: Re: Makefile.in files > > > > separate area. We use CVS with automake and in our source trees when > we do a cvs update -d it shows all

Re: Problems with AMDEP does not appear in AM_CONDITIONAL

Have you run aclocal ? Rob - Original Message - From: "Adam Tee" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, October 12, 2001 6:47 PM Subject: Problems with AMDEP does not appear in AM_CONDITIONAL > Hi all, > > I've just upgraded my machine to use automake 1.5 and autoconf

Tom Tromey PING!

Tom, I posted a question about getting the size reduction for Makefile's using AM_COND's backported in to a 1.5 stable release... so far there has been 1 reply, which amounted to "that would be good"... I presume you are backlogged overthere, but we @ squid-cache.org are approaching a new

Re: Tom Tromey PING!

- Original Message - From: "Akim Demaille" <[EMAIL PROTECTED]> To: "Robert Collins" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, October 15, 2001 6:25 PM Subject: Re: Tom Tromey PING! > >>>>> "Robert" == Ro

Re: Tom Tromey PING!

- Original Message - From: "Akim Demaille" <[EMAIL PROTECTED]> To: "Robert Collins" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, October 15, 2001 6:46 PM Subject: Re: Tom Tromey PING! > >>>>> "Robert" == Robe

BUG: Solaris make & automake, VPATH, subdir sources and SUBDIR_OBJECTS

Sumamry for automake: automake 1.5 with VPATH builds using the Sun make environment and subdirectory sources and SUBDIR_OBJECTS is failing due to partial pattern replacement by the Sun make on the explicit .c.o rule. The implicit rule works fine. I'm happy to prep a patch for this, but which of

Re: Solaris make & automake, VPATH, subdir sources and SUBDIR_OBJECTS

D'oh! - Original Message - From: "Robert Collins" <[EMAIL PROTECTED]> > 2) Only emit explicit rules when the sources ARE in the same relative ^^^ NOT > dir i

Re: linking against a freshed libtoolized library

Just link against the .la file. Automake then gets libtool to do the rest. Rob - Original Message - From: "Stéphane Genaud" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, October 16, 2001 10:44 PM Subject: linking against a freshed libtoolized library Hi, I would like my M

Re: help with AC_CHECK_LIB, AC_TRY_LINK

wrong list, you want the autoconf list, not automake for this. Rob

PR224

I note that this PR is still open - It was filed as serious (and IMO :} it is). What chance of this being addressed before 1.5b goes beyond testing? Rob

Re: PR224

- Original Message - From: "Tom Tromey" <[EMAIL PROTECTED]> > > I looked at this PR. Why do you want this change? > > Right now if you write: > > AUTOMAKE_OPTIONS = subdir-objects > bin_PROGRAMS = wish > wish_SOURCES = generic/a.c generic/b.c > > ... you end up with `.deps/gen

Re: some distributed header problem

xxx_SOURCES = $(top_srcdir)/headers/foo.h but this is buggy right now (see the thread PR 224). as for #2, read the FAQ/documentation. You should anyway. for #3, also same answer as for #2. Rob - Original Message - From: "cityhunter x-y-z" <[EMAIL PROTECTED]> Subject: some distributed

http://www.gnu.org/software/automake/

There's no link to the sources.redhat.com/automake site at the project page on gnu.org. IMO such a link would be helpful. Rob

Re: automake parallel install

=== - Original Message - From: "Tim Van Holder" <[EMAIL PROTECTED]> > This solution keeps $prefix/bin fairly uncluttered, moving the many > scripts below their own tree under $prefix/shared/. I think this is > what's done by the autoconf & automake wrappers used by cygnus, but I'm > not

Re: PR224

=== - Original Message - From: "Tom Tromey" <[EMAIL PROTECTED]> To: "Robert Collins" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, January 21, 2002 8:22 AM Subject: Re: PR224 > >>>>> "Rob" == Robert Col

RE: RFC: ./configure or ./config.status --clean

I think there are valid points to both the 'tools don't clean up after themselves' and the 'autoconf and automake shouldn't be in lockstep' arguments. IMO autoconf will make life easier for both automake and non-automake users by providing a clean capability of it's own. That in itself should mak

`AC_LIBOBJ vs. LIBOBJS'

I get this with automake 1.6... configure.in:538: error: do not use LIBOBJS directly, use AC_LIBOBJ (see section `AC_LIBOBJ vs. LIBOBJS' yet the info pages don't seem to have such a section. Where is this documented? (And what should I change). Rob

RE: `AC_LIBOBJ vs. LIBOBJS'

> -Original Message- > From: Alexandre Duret-Lutz [mailto:[EMAIL PROTECTED]] > Sent: Friday, April 05, 2002 12:07 AM > To: Robert Collins > Cc: [EMAIL PROTECTED] > Subject: Re: `AC_LIBOBJ vs. LIBOBJS' > > > Hi Robert, > > >>> "Rob

RE: Large project support

> -Original Message- > From: Timo K Suoranta [mailto:[EMAIL PROTECTED]] > Sent: Thursday, April 11, 2002 5:41 PM > > > Wildcards are unreliable, and with automake we try to > promote reliable > > builds. For instance that is why we use full instead of partial > > dependency informa

RE: maintainer mode

> -Original Message- > From: Roger Leigh [mailto:[EMAIL PROTECTED]] > Sent: Friday, April 12, 2002 6:05 AM Doing this allows us to > require only developers to have a greater set of tools to be > installed and configured, without passing on the burden to our users. Ditto for squid.

RE: Large project support

> -Original Message- > From: Tom Tromey [mailto:[EMAIL PROTECTED]] > Sent: Saturday, April 13, 2002 7:24 AM > Also this happens a lot in libjava, where we sometimes add a > new .java file without touching anything else. I imagine the > same is true for many Java libraries. And in a

RE: maintainer mode

> -Original Message- > From: Tom Tromey [mailto:[EMAIL PROTECTED]] > Sent: Saturday, April 13, 2002 6:59 AM > To: Robert Collins > Cc: Roger Leigh; Alexandre Duret-Lutz; Chadwick A. McHenry; > GNU Automake List > Subject: Re: maintainer mode > > >

RE: Large project support

> -Original Message- > From: Robert Collins > Sent: Saturday, April 13, 2002 12:01 PM > > -Original Message- > > From: Tom Tromey [mailto:[EMAIL PROTECTED]] > > Sent: Saturday, April 13, 2002 7:24 AM > > > Also this happens a lot in libja

RE: Seeking simple example for "shallow" tree

> -Original Message- > From: Bruce Korb [mailto:[EMAIL PROTECTED]] > Sent: Saturday, April 13, 2002 10:03 AM > To: Ian Pilcher > Cc: [EMAIL PROTECTED] > Subject: Re: Seeking simple example for "shallow" tree > > > Ian Pilcher wrote: > > > > I am trying to set up a simple project for

nobase_ room for improvement

Just an idea. I use automake to make non-recursive build environments fairly routinely now. (Recursive-make-considered-bad ...) Installation of headers in subdirectories is more complex than it could be (IMO). The nobase_ prefix allows utilising an existing directory tree, but a non-recursive b

distcheck with libtool

testoption_SOURCES = tests/testoption.cc testoption_LDADD = libgetopt++.la == configure.in == dnl dnl Configuration input file for GetOpt++ dnl dnl Robert Collins, [EMAIL PROTECTED] dnl dnl $Id: configure.in,v 1.5 2002/03/01 12:14:39 robertc Exp $ dnl dnl dnl AC_INIT(src/GetOption.cc) AC_PREREQ

RE: nobase_ room for improvement

> -Original Message- > From: Tom Tromey [mailto:[EMAIL PROTECTED]] > Sent: Sunday, April 14, 2002 10:40 AM > Rob> While defining a new target to be $(includedir)/foo lets > you work > Rob> around this, it would be great to do something like: > Rob> nobase_preserve_foo_HEADERS = ...

.la files from outside the current project

When I put the following: bin_PROGRAMS = foo foo_SOURCES = src/foo.cc foo_LDADD = libbar.la into a Makefile.am, the foo_DEPENDENCIES target gets libbar.la added - even though it's not included in the source. libbar.la is present in /usr/lib or /usr/local/lib. How can I avoid the auto-setting of

RE: nobase_ room for improvement

> -Original Message- > From: Alexandre Duret-Lutz [mailto:[EMAIL PROTECTED]] > Sent: Sunday, April 14, 2002 8:15 PM > As a generalization of this and Tom's _NAME, what about: > > nobase_include_HEADERS = ... > nobase_include_HEADERS_TRANSFORM = s,^foo/bar/delta/,, > > This would be s

Re: Large project support

ell to make much use of Automake/Autoconf/Libtool, so go ahead and jump in. HTH, Robert #! /bin/sh -x # # File:domake # Language: shell # Purpose: Create Makefile.am'

FW: sed: 33: conftest.s1: unescaped newline inside substitute pattern

_aux_dir && pwd` > > > > am_aux_dir=`CDPATH=:; cd ./$ac_aux_dir && pwd` > > > Ah, now I know why I cannot reproduce the problem. I always > build in an object tree separate from the source. > > The second approach cannot be used. $a

RE: FW: sed: 33: conftest.s1: unescaped newline inside substitutepattern

> -Original Message- > From: Alexandre Duret-Lutz [mailto:[EMAIL PROTECTED]] > Sent: Thursday, April 18, 2002 6:58 PM > Yes, it's fixed in 1.6. Thanks. Rob

RE: Creting extra executables.

Always create the gui makefile. Use a configure substitution to change the value of SUBDIRS, and use DIST_SUBDIRS to ensure that all the code gets distributed. Rob

RE: non-recursive project example

Here's one.. I've got another more complete example with installable libraries and headers if needed, but it's somewhat longer. This is a trimmed down file from a current project. Rob ## Process this file with automake to produce Makefile.in # # $Id: Makefile.am,v 1.3 2002/01/13 14:16:17 robertc

RE: non-recursive project example

> -Original Message- > From: Alexandre Duret-Lutz [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, April 23, 2002 10:07 PM > To: Robert Collins > Cc: Tim Waugh; [EMAIL PROTECTED] > Subject: Re: non-recursive project example > > > >>> "Rober

RE: non-recursive project example

> -Original Message- > From: Alexandre Duret-Lutz [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, April 23, 2002 10:26 PM > To: Robert Collins > Cc: Tim Waugh; [EMAIL PROTECTED] > Subject: Re: non-recursive project example > > > >>> "Rober

RE: non-recursive project example

> -Original Message- > From: Alexandre Duret-Lutz [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, April 23, 2002 10:48 PM > To: Robert Collins > Cc: Tim Waugh; [EMAIL PROTECTED] > Subject: Re: non-recursive project example > > > >>> "Rober

lex & yacc with C++ projects

It would be nice to be able to tell automake that we want to compile the out of lex and yaxx with g++, not gcc. (this is for C++ projects). Is there any way to do this currently? At the moment I've got the .cc files listed as BUILT_SOURCES, and custom rules to make them. This isn't very satisfac

RE: lex & yacc with C++ projects

> -Original Message- > From: Robert Collins > Sent: Friday, April 26, 2002 7:18 PM > To: [EMAIL PROTECTED] > Subject: lex & yacc with C++ projects > > > It would be nice to be able to tell automake that we want to > compile the out of lex and yaxx wit

per object cflags

Are there any plans to allow per object CFLAGS (and CXXFLAGS...)? I've got a projec that I want to put -Werror into the AM_C[XX]FLAGS variable, but a couple of files won't compile without warnings. The warnings are harmless, almost compiler bugs in fact, so fixing the source isn't feasible there.

RE: lex & yacc with C++ projects

> -Original Message- > From: Guido Draheim [mailto:[EMAIL PROTECTED]] > Sent: Friday, April 26, 2002 8:57 PM > To: Robert Collins; [EMAIL PROTECTED] > Subject: Re: lex & yacc with C++ projects > > > Es schrieb Robert Collins: > > > > It would

RE: lex & yacc with C++ projects

> -Original Message- > From: Guido Draheim [mailto:[EMAIL PROTECTED]] > Sent: Friday, April 26, 2002 9:49 PM > hhh. even though I need some enlightment what's wrong with a > libstdc++ dependency for a c++ compiled source - so your project > uses c++ files without libstdc++ and you

RE: Sending _OBJECTS output to configuration specific directory - HELP!!

Run the configure script twice. Once from $(srcdir)/build/Release with CFLAGS=-O3 CXXFLAGS=-O3 Once from $(srcdir)/build/Debug with CFLAGS="-O -g" CXXFLAGS="-O -g" Cheers, Rob

RE: monolithic Makefile.am

> -Original Message- > From: Tom Tromey [mailto:[EMAIL PROTECTED]] > Sent: Sunday, May 05, 2002 11:18 AM > Long term I'd like us to ease this sort of thing. > > My working idea is to have a new `import' command which is > like `include' but understands about directory structure. So

RE: monolithic Makefile.am

In fact, here are some of the references... http://sources.redhat.com/ml/automake/2001-08/msg00061.html http://sources.redhat.com/ml/automake/2001-08/msg00088.html http://sources.redhat.com/ml/automake/2001-08/msg00109.html http://sources.redhat.com/ml/automake/2001-08/msg00113.html Msg 113 high

RE: lex & yacc with C++ projects

> -Original Message- > From: Tom Tromey [mailto:[EMAIL PROTECTED]] > Sent: Monday, May 06, 2002 3:45 PM > Do you have other C files that you want to compile with > $(CC)? If not you could set `CC = $(CXX)'. (This is pretty ugly.) We have a .c file that generates linker stubs for ob

RE: per object cflags

Done I think.. the GNATS web returned to the entry screen without giving me a PR number, so I'm not sure.. Rob > -Original Message- > From: Tom Tromey [mailto:[EMAIL PROTECTED]] > Sent: Monday, May 06, 2002 3:38 PM > To: Robert Collins > Cc: [EMAIL PROTECTED] >

RE: monolithic Makefile.am

> -Original Message- > From: Tom Tromey [mailto:[EMAIL PROTECTED]] > Sent: Sunday, May 12, 2002 9:15 AM > To: Robert Collins > Cc: Richard Boulton; Harlan Stenn; Automake > Subject: Re: monolithic Makefile.am > > > >>>>> "Rob" ==

Re: Alternate automake output?

=== - Original Message - From: "William Robertson" <[EMAIL PROTECTED]> To: "Tom Tromey" <[EMAIL PROTECTED]> > I know this is a hack, but could automake play along with this, and > would this work? Alternatively, is there a cleaner way to achieve this > goal? I'd just use subdir_objects

RE: linking with libtool

Title: RE: linking with libtool FYI,  Libtool mailing lists seem to be working again.   - Robert -Original Message-From: Boehne, Robert Sent: Friday, July 19, 2002 8:24 AMTo: 'Alexandre Duret-Lutz'; Enrico NgCc: [EMAIL PROTECTED]Subject: RE: linking wi

Re: Option no-gzip

On Sat, 2002-07-27 at 02:25, Bruce Korb wrote: > Akim Demaille wrote: > > > > Would that be accepted? For some of my projects, I don't need nor > > want the .gz, I just want the .bz2. > > If you are going to parameterize it at all, then parameterize it > completely. e.g. --compressor=bzip2 [

Re: Option no-gzip

On Mon, 2002-07-29 at 13:14, Bruce Korb wrote: > Robert Collins wrote: > > > > On Sat, 2002-07-27 at 02:25, Bruce Korb wrote: > > > Akim Demaille wrote: > > > > > > > > Would that be accepted? For some of my projects, I don't need nor >

Re: Option no-gzip

On Tue, 2002-07-30 at 18:11, Alexandre Duret-Lutz wrote: > >>> "Robert" == Robert Collins <[EMAIL PROTECTED]> writes: > > [...] > > Robert> This means: > Robert> build dist tree > Robert> compress with compressor 1 > Robert> compr

Re: Option no-gzip

On Tue, 2002-07-30 at 19:02, Alexandre Duret-Lutz wrote: > >>> "Robert" == Robert Collins <[EMAIL PROTECTED]> writes: > > [...] > > Robert> Still I don't see how that could be accomplished with Bruce's > Robert> suggestion of multipl

Re: Pathalogical behavior with "more" AM_CONDITIONAL()s?

On Thu, 2002-08-01 at 09:34, Harlan Stenn wrote: > I have a report that indicates that as the number of AM_CONDITIONAL()s > increases, the time it takes to run automake increases Significantly. > > This is with automake-1.5. > > I'm about to dive in and look at what's going on to be sure, but ju

Re: Pathalogical behavior with "more" AM_CONDITIONAL()s?

On Thu, 2002-08-01 at 12:55, Harlan Stenn wrote: > Here are the results of my testing: > > someconditionals/: > automake-1.5:249.480u 2.660s 4:42.35 89.3% 0+0k 0+0io 341pf+0w > automake-1.6.3: 341.810u 2.840s 6:07.24 93.8% 0+0k 0+0io 356pf+0w > > moreconditionals/: > a

Re: top-level Makefile required?

On Sat, 2002-08-03 at 09:55, Harlan Stenn wrote: > Is it a bug or a feature that when using automake+autoconf there Must be a > top-level Makefile? > > I tried to write a test case for automake (debugging the AM_CONDITIONAL > slowdown problem I'm seeing) and I wrote a top-level configure.ac that

Re: Pathalogical behavior with "more" AM_CONDITIONAL()s?

On Sat, 2002-08-03 at 09:50, Harlan Stenn wrote: > I've done a bit more testing. > > The slowdown happens if I only modify 1 Makefile.am, and it seems to be > related to using SUBDIRS inside an AM_CONDITIONAL. > > If I change the Makefile.am to use a non-SUBDIRS variable inside the > conditional

Re: top-level Makefile required?

On Sat, 2002-08-03 at 10:02, Harlan Stenn wrote: > Bug, I'd guess. > > Why does automake/autoconf assume it is "in charge" of the directory > structure? I'll leave this to the core guys to answer. My understanding is that thats what automake is designed to handle though.. Rob

Re: about vpath problems

On Thu, 2002-08-15 at 02:01, Tom Tromey wrote: > > ">" == leiming xd <[EMAIL PROTECTED]> writes: > > >> In win32 platforms ,the path of one file can include blank > >> characters,I want to know how to add this path in the vpath. > > I imagine it may not be possible. If it can work, autoconf

Autoshell documentation

Is there a good reason, other than nobody getting around to it yet, that the only Autoshell macros that've been documented are AS_DIRNAME & AS_MKDIR_P? Derek -- *8^) Email: [EMAIL PROTECTED] Get CVS support at ! -- Coffee is not for kids. Coffee is not for ki

AM_PROG_CC_C_O (was Re: AC_PROG_CC_O and Re: wierd test inconfigureon bug-cvs)

Hey Jim, sorry, I just looked this up and it appears that I reported on the wrong macro (kinda), to the wrong list (kinda), and that there was a reason for it after all. Jim Meyering wrote: I think it was designed to be used mainly in GNU Make's configure.ac file. From the description, you get

Re: delete aclocal.m4? keep generated files on cvs server? enforcespecefic automake/conf version?

Bjarke Freund-Hansen wrote: I'm new at developing on POSIX systems, so I have a few questions (as the subject might indicate ;)) Should I include aclocal.m4 in MAINTAINERCLEANFILES, and regenerate it every time i regenerate the built files? (runs autogen.sh) It depends whether you want to expect e

Re: make -q

> Is make -q portable? If so I could speed up my parallel built source > patch somewhat. SunOS 4.1.3 has it. --Robert -- Robert S. Maier | Internet: [EMAIL PROTECTED] Dept. of Math.| Univ. of Arizona | FAX: +1 520 621 8322 Tucson, AZ 85721 | Voice: +1 520 621 6892 (depa

Can't find the correct set of libs on FC5/x64

I'm currently taking a course in graphics programming with OpenGL, and thought it would be kind of me to turn in assignments which are ./configurable. My desktop environment is an OS X box, and the TAs are running a variety of different Unices. This seems like a job for Autotools, so I set up a m

Re: amhello build prob

Ralf Wildenhues wrote: > Never mind what I wrote. Please. After the sea of good bits that have flowed from your PC in the last few months, Ralf, I think we're all just going to attribute whatever was wrong to TCP transmission error. It was time for a bad packet anyway. Resend? Thanks very much,

Sablotron and Autotools?

For a project I'm working on, I need a crossplatform XML inspector. GDOME2 is out because it doesn't work on OS X, so we're instead looking at Sablotron. Looking at the Autoconf Archive I don't see any m4 macros for Sablotron, nor does it come with a pkg-config file. What is the canonical

Re: autotools on mac os x

Could you give me an hand, i have been searching for 2 entire days.. Try Fink. http://fink.sourceforge.net

Re: How to build source code while treating all warnings as errors with automake...

jasond wrote: Recently, I converted the project over to using Autotools and am wondering if there is a portable way to instruct automake to generate Makefiles that build code while treating all encountered warnings as errors? Probably so, and I'm sure Ralf will know what it is. However, this i

Re: Bison C++ parsers and ylwrap

Ralf Wildenhues wrote: > It probably is a bug. I for one use bison/yacc very sparingly only and > lack the experience how to deal with it portably. Which is why it would > be better if someone else worked on fixing it. For whatever it's worth, I have always found bison's C++ support to be sub-p

Re: Report to stdout like Linux kernel compilation does

Bob Proulx wrote: To give you a different perspective, I *hate* that format because it hides problems and *makes debugging harder*. I want to see exactly the command that was executed. I want to see the entire command. I don't want to see an abbreviation of the command. Fortunately, no one i

Re: Report to stdout like Linux kernel compilation does

John Calcote wrote: > Hmmm. I'd have to disagree here. I carefully consider every warning I > see, and evaluate whether or not it represents a real problem. Yes. This strikes me as perfectly sane behavior. Insisting on warning-free builds is not sane behavior, especially given just how many comp

Setting output dir for support files

I've used Autotools in a few small projects before, but nothing which required auxiliary files to support the binaries. Typically, I've seen these auxiliary files stored in /usr/share/package-version/, and would like to do the same thing for my own package via Autotools. I'm able to get /usr/shar

Re: Building prog first

On 3/22/10 6:50 PM, John Calcote wrote: > Reuben, you've just hit upon one of the two most significant problems > with Javadoc and the like (including doxygen, man pages, and info pages): Agreed -- which is why I think it would be wonderful if there was strong Autotools support for literate progra

Re: call for help/crazy idea: nmake support

On 8/1/2010 2:11 PM, Ralf Wildenhues wrote: > So let me rephrase the question: if we have the ability to build > completely with MSVC within a shell environment such as MinGW/MSYS > would people still need something like nmake support? Speaking for myself and my projects -- no, I would not.

Re: GNU make or portable make? (was: Makefile to Makefile.am)

> I for one would be glad if automake required GNU make, since it > could make use of a lot of useful features which currently aren't > allowed. Similar to autoconf not requiring a POSIX shell, depite > the fact that non-POSIX shells are so far obsolete they are > irrelevant. Are there any tools

Re: built files in CVS

"Steve M. Robbins" wrote: > Hello, > > I presume the automake developers track the CVS tree and > frequently build new versions of automake for testing. > Could you let us in on the secret to minimizing the following > annoyance? > > The CVS tree includes things like Makefile.in. But this file >

New documentation targets (pdf & txt)

Here are several generic rules for creation of PDF and ASCII output from *.texinfo files in case anyone is interested. Both rules use makeinfo so they shouldn't create any new dependencies and the input and output file sets are the same as for *.info files, except do a s/\.info$/.pdf/ or s/\.info

Re: New documentation targets (pdf & txt)

Derek Robert Price wrote: > *.texinfo files in case anyone is interested. Both rules use makeinfo > so they shouldn't create any new dependencies and the input and output Excuse me. The PDF rule does use texi2dvi as well, but that seems to be used in Automake generated `Makefile.i

Re: Meta-issue: recent spam surge

"Lars J. Aas" wrote: > On Thu, Sep 13, 2001 at 11:03:45AM +0100, Lars Hecking wrote: > : > : http://mail.gnu.org/pipermail/automake/2001-September/date.html > : > : What a sad sight: fully one third of all list messages for this month > : are spam. Other lists at gnu.org (and elsewhere) have b

Re: built files in CVS

"Steve M. Robbins" wrote: > Clearly, built files can be recovered from their sources, so why > put them into version-control? I wasn't in on the original decision, but I believe the rationale on the CVS project was that we wanted a checkout to look like a distribution tarball to make it easier f

<    1   2   3