race condition with subdir objects:

the following will break on distclean aith automake 1.7.5: Makefile.am: SUBDIRS=a AUTOMAKE_OPTIONS = subdir-objects bin_PROGRAMS=foo foo_SOURCES=a/foo.cc a/Makefile.am bin_PROGRAMS=bar bar_SOURCES=bar.cc The failure is because subdirs are distcleaned first, and a/.deps is rm -rf'd before the

Re: convenience binaries

On Mon, 2003-09-22 at 19:56, Warren Turkal wrote: > Is there any support in automake for building a binary that will only be > used during the build process? yes, noinst_PROGRAMS = convenience_binaries any rules that depend on one of the binaries should be written as: thing: binary$(EXEEXT)

Re: convenience binaries

On Mon, 2003-09-22 at 21:22, Warren Turkal wrote: > Robert Collins wrote: > > yes, > > noinst_PROGRAMS = convenience_binaries > > Can these convenience programs be built for the host arch in a > cross-compiled environment? probably, you'll likely need to override th

Re: convenience binaries

On Mon, 2003-09-22 at 22:31, Andrew Suffield wrote: > On Mon, Sep 22, 2003 at 10:01:24PM +1000, Robert Collins wrote: > > On Mon, 2003-09-22 at 21:22, Warren Turkal wrote: > > > Robert Collins wrote: > > > > yes, > > > > noinst_PROGRAMS = convenience_b

Re: Should -i mkdir?

On Sat, 2003-09-27 at 02:20, Alexandre Duret-Lutz wrote: > adl> autopoint and libtoolize usually run before automake > adl> and put things into this directory too. So if some tools has to > adl> create the directory, I think it should be autopoint. > > Sorry, I meant "it should be autoreconf"

Re: precompiled header suggestion

On Wed, 2003-10-01 at 04:30, Tom Tromey wrote: > Recently gcc added precompiled header support. This is mostly useful > for C++, but C might benefit in some cases too. Waay cool. Are you planning on doing this, or just sketching the design and hoping for volunteer contributions? What might be a

Re: Aborting automake?

On Sat, 2003-11-08 at 11:22, Harlan Stenn wrote: > I have a situation where I want every Makefile.am to 'include' one of > several files. > > If none of these files are 'include'd I want the automake run to abort. > > I know how to cause the abort at runtime, but I'd rather catch this problem > w

Re: Non-recursive make & intermediate objects

On Thu, 2003-11-20 at 09:04, Bob Friesenhahn wrote: > Using Automake 1.7.9, I am attempting to create a single Makefile.am > which is capable of building all of the libraries used by the project. > The source files to the project are located in subdirectories, and the > output libraries should also

Re: Non-recursive make & intermediate objects

On Thu, 2003-11-20 at 09:50, Bob Friesenhahn wrote: > On Thu, 20 Nov 2003, Robert Collins wrote: > > > subdir_objects in your automake options. > > > > Problem is, there is a design headache that makes recursive clean fail > > with this approach - I forget the bu

Re: Non-recursive make & intermediate objects

On Sat, 2003-11-22 at 07:12, Bob Friesenhahn wrote: > So this bug is only present if SUBDIRS is used to cause the Makefile > to also have a recursive aspect. Yes - which projects that include other projects will need. Or for things like test scripts, I find throwing them in a sandbox of sorts muc

failure building HEAD

checking whether autoconf is installed... yes checking whether autoconf works... no configure: error: The installed version of autoconf does not work. Please check config.log for error messages before this one. I get the above configuring CVS automake. from config.log: configure:1819: eval a

non recursive includes proof of concept #2

Well, I finally snuck in a little time to update my proof of concept for non recursive includes. Still, I don't code perl - and it shows ;). How to use? Grab CVS automake, apply thepatch, drop the test files into tests subdir. Have a look at the test cases to see how to use it. What does it do

Re: failure building HEAD

On Mon, 2003-12-01 at 18:09, Alexandre Duret-Lutz wrote: > >>> "Robert" == Robert Collins <[EMAIL PROTECTED]> writes: > > [...] > > Robert> configure:1847: cd conftest && eval autoconf -o /dev/null conftest.ac > Robert> autom4te: cann

Re: Non-recursive make & maintenance issue

On Fri, 2003-11-28 at 04:29, Bob Friesenhahn wrote: > It is not a problem as long as Automake provides sufficient > automatic translation capabilities. There just needs to be a standard > way to create definitions and refer to existing definitions, including > those that Automake generates for it

Re: Non-recursive make & maintenance issue

On Fri, 2003-11-28 at 03:49, Jirka Hanika wrote: > My view is that these (and other) problems disappear if you use a > per-directory Makefile.am; but I also see the benefits (esp. compilation > speed) of a non-recursive Makefile. So the solution could be to support > generating a single Makefile

oops, regression - updated proof of concept - #2a

A minor oversight led to a regression, which I caught when the test cases finished running... here's a replacement patch. (Still use the test cases from my previous email). Rob -- GPG key available at: . Index: automake.in ===

Re: Non-recursive make & maintenance issue

On Tue, 2003-12-02 at 07:08, Bob Friesenhahn wrote: > By 'read only', I mean that there is an existing source tree with no > Makefile.am's (perhaps it uses some other build system) and you are > not allowed to (or shouldn't) update it. Since Automake supports > subdirectories, the Makefile.am does

Re: Non-recursive make & maintenance issue

On Tue, 2003-12-02 at 02:10, Bob Friesenhahn wrote: > > Hmm, I'd prefer to do it via the include mechanism - see my crude, but > > effective updated proof of concept - posted here a minute ago. > > I like your include approach. It helps convert existing recursive > builds into non-recursive build

Re: failure building HEAD

On Tue, 2003-12-02 at 21:44, Alexandre Duret-Lutz wrote: > I think this is the problem. Ben, you cannot write > `$output.tmp' because when $output is /dev/null a user cannot > create /dev/null.tmp. This change breaks the configuration of > all versions of Automake since 1.6 :( Yah, so, the right

Re: Non-recursive make & maintenance issue

On Wed, 2003-12-10 at 05:06, Tom Tromey wrote: > It isn't impossible. I once wrote up some ideas along these lines: > > http://sources.redhat.com/ml/automake/2001-07/msg00248.html > > Obviously I never got around to implementing this :-) Have you looked at either of my proof-of-concepts?

non-recursive via includes

Ok, I plan to push this through a little closer to completion (some feedback from the maintainers would be greatly appreciated !) I've created a branch for this in arch: [EMAIL PROTECTED]/automake--nonrecursive--1.8 The arch repository is at http://people.initd.org/robertc/automake/ (G

HEAD test suite - 6 failures.

Are the following tests known to fail (on debian unstable): FAIL: ccnoco.test FAIL: gnits2.test FAIL: gnits3.test FAIL: pr300-lib.test FAIL: pr300-prog.test FAIL: python3.test Cheers, Rob -- GPG key available at: . signature.asc Description: This is a di

Re: HEAD test suite - 6 failures.

On Thu, 2003-12-18 at 20:00, Alexandre Duret-Lutz wrote: > >>> "Robert" == Robert Collins <[EMAIL PROTECTED]> writes: > > Robert> Are the following tests known to fail (on debian unstable): > > Nein, no tests are known to fail. What does VERBOSE=x say

Re: HEAD test suite - 6 failures.

On Sat, 2003-12-20 at 00:47, Alexandre Duret-Lutz wrote: > Robert> that the scripts in lib/ aren't chmodded correctly. > > Why aren't they? How did they loose their permissions? Errm, that was my fault. An oversight in a cvs extracting tool, that I wasn't aware of at the time. > Robert> Perh

Re: non recursive includes proof of concept #2

On Sat, 2003-12-20 at 00:41, Alexandre Duret-Lutz wrote: > >>> "Robert" == Robert Collins <[EMAIL PROTECTED]> writes: > > [...] > > Robert> It transforms macros and paths in an included file (called > Robert> Makefile.rules for now) , to make t

Re: Expressing dependencies

On Sun, 2004-01-04 at 08:17, Laurence Finston wrote: > The problem is that make makes certain assumptions that don't apply when CWEB > is used. I think thats an incorrect statement. It would be more accurate to say that CWEB hasn't been built with any thought to the impact on make. Make has only

Re: Expressing dependencies

On Mon, 2004-01-05 at 03:53, Laurence Finston wrote: > This is essentially what I tried to do by using the auxiliary program > `3DLDFcpl' in the rule for building the executable `3dldf' (roughly): > > 3dldf: $(3DLDF_CWEBS) >3DLDFcpl Thats not quite what I was suggesting. > Not changing

Re: pathnames containing spaces

On Thu, 2004-01-29 at 00:08, Earnie Boyd wrote: > Good luck with fixing the white space problems in every process that > reads arguments and uses white space as a delimiter of some sort. Earnie has a very good point - GNU Arch faces the same problem with a limited set of tools - patch, diff and t

Re: RFC: doc for `Handling Tools that Produce Many Outputs'

On Sun, 2004-02-01 at 09:28, Alexandre Duret-Lutz wrote: > This is a new section I'd like to add to the FAQ. It has been > discussed two or three times on the list. > > I'm posting it here for comment. (In fact I'm mainly hoping > that some kind fellow will point out English mistakes...) Cute.

Re: RFC: doc for `Handling Tools that Produce Many Outputs'

On Thu, 2004-02-05 at 10:36, Eric Siegerman wrote: > I believe this fails on the following corner case. Suppose the > date ordering is like this (with data.h being the oldest): > data.h data.foo data.c > > data.h is out of date with respect to data.foo, so one wants to > rebuild it, bu

Re: non-recursive make and tests

On Mon, 2004-08-30 at 20:30 -0500, Bob Friesenhahn wrote: > On Mon, 30 Aug 2004, Bob Friesenhahn wrote: > > > > It would be quite helpful if Automake offered a mode in which it > > automatically changed the working directory to the directory where the test > > program/script resides and set $srcd

Re: Automake and new tar

On Thu, 2004-11-25 at 21:59 +0100, Christian Fredrik Kalager Schaller wrote: > Hi Automake hackers, > > I am maintainer of a GNOME module called gnome-themes-extras containing > a set of metathemes for the GNOME desktop. After upgrading my distro I > have been unable to 'make dist' gnome-themes-e

Re: How to setup an example programs subdirectory?

On Sat, 2005-01-01 at 20:24 -0500, Simon Perreault wrote: > Hi, > > I have a question for which I haven't been able to find an answer on my own, > using the usual resources (manual, google, etc). > > My project uses automake and I want to have a directory containing example > programs. These pr

Re: Configuring automake says autoconf 2.58 or higher needed. Have au toconf 2.59 installed. What is/goes wrong?

On Sun, 2005-01-16 at 07:01 -0500, Thomas Dickey wrote: > On Sun, 16 Jan 2005, Ralf Corsepius wrote: > > > On Sat, 2005-01-15 at 13:15 +0100, Alexandre Duret-Lutz wrote: > > > >> PS: I know this is not the first time, but I simply do not > >> understand why you respond to bug reports without C

Re: Configuring automake says autoconf 2.58 or higher needed. Have au toconf 2.59 installed. What is/goes wrong?

On Mon, 2005-01-17 at 03:18 +, Andrew Suffield wrote: > Only the > sender can do anything better than this, because they're the only one > with the necessary information. Its not at all clear to me that they have sufficient information. Rob -- GPG key available at:

Re: [GSoC] Early design discussion for TAP/SubUnit support in automake.

Very sorry for the slow response, been EBUSY with real-life. On Sun, May 22, 2011 at 11:42 PM, Stefano Lattarini wrote: > On Sunday 22 May 2011, Ralf Wildenhues wrote: >> Hi Stefano, and sorry for the long delay, >> > No problem, you had warned me in due time about such possible delays this > mon

Re: [GSoC] Early design discussion for TAP/SubUnit support in automake.

On Thu, Jul 7, 2011 at 7:03 AM, Stefano Lattarini wrote: > Hello Robert. >> >> >> > OTOH, I do believe this is a real concern, to be carefully addressed and >> > tested for.  Thanks for bringing this up. >> >> For Both TAP and subunit the test script running needs to feed into a >> single parser:

Re: Automake violations of the gnu coding conventions

On Mon, 2007-06-18 at 17:27 -0700, K. Richard Pixley wrote: > > My question today is... is there any hope of bringing automake > generated > Makefiles back into line with the GNU coding standards so that these > applications will work once again? Use AM_MAINTAINER_MODE in your package; this wi

Re: Strictness

On Sat, 2007-08-11 at 22:06 +0200, Carl Fürstenberg wrote: > On 8/11/07, Noah Slater <[EMAIL PROTECTED]> wrote: > > > I think you misunderstanding me, it's the generation if the changelog > > > that will take too long time. > > > > Well, yes - what else could I have understood from: > > > > > That

Re: Strictness

On Sun, 2007-08-12 at 23:40 +0100, Noah Slater wrote: > > I disagree. In a centralised VCS sure, you can scale to 100's of commits > > a day - but in a distributed VCS - e.g. bzr, git, hg, monotone ... you > > tend to get 100's of commits on branches, and a much smaller number of > > branch merges

Re: Automatically Handling Tools that Produce Many Outputs

On Mon, 2007-12-10 at 21:51 +, Olly Betts wrote: > > I can't think of a way to easily dig out statistically useful data > from a VCS or Google code search on how often it happens either to me > or > generally. But I mainly offered it as a more concrete example of the > sort of issues I had i

Re: Modifying CFLAGS for 'make distcheck'

On Sat, 2008-02-09 at 14:52 -0600, Bob Friesenhahn wrote: > On Sat, 9 Feb 2008, Ralf Wildenhues wrote: > > > > If *that* were still a concern for a compression tool (as opposed to > > various vendor `tar' programs), then heck it should not be promoted at > > all for wider use. No, I don't think e

Re: rebuilding following a change in prefix?

On Fri, 2009-05-08 at 06:52 +0200, Jan Engelhardt wrote: > Well, automake (unfortunately?) does not currently issue a recompile > when the compiler command changed. > It would be really cool to have that, though. Write the compiler command to a file (stamp-compiler). make things depend on that f

Re: invoke pkg-config with --static

On Sat, 2009-05-16 at 19:04 -0500, Bob Friesenhahn wrote: > On Sat, 16 May 2009, Lorenzo Bettini wrote: > > > when ./configure is run with --disable-shared, is there a way to invoke the > > pkg-config macro with --static (so that it does not select private > > libraries > > in the .pc file)? >

Re: My project can't use `silent-rules'

On Sun, 2009-05-17 at 15:43 -0500, Bob Friesenhahn wrote: > The reason why my package can not use AC_INIT is that the package > version information is (often) computed by shell script code based on > the last entry in the project ChangeLog or other information. It is > (apparently) not possibl

Re: invoke pkg-config with --static

On Sat, 2009-05-23 at 18:18 +0200, Lorenzo Bettini wrote: > Ralf Wildenhues wrote: > > Of course, as soon as you propose your software for packaging at > > debian.org, they will count not using .Private as bug ... ;-) > > uh! Good to know that! Thanks :-) This is because when you link against

distcheck and uninstall

It would be nice if there was an option to tell automake not to (do 'uninstall' as part of distcheck | require that uninstall leaves no files behind) distcheck is very useful, it catches many distribution related bugs like missing EXTRA_DIST and so on. However, uninstall as a target is much less

Re: distcheck and uninstall

On Sat, 2009-09-19 at 08:24 +0200, Ralf Wildenhues wrote: > Hello Robert, > > * Robert Collins wrote on Sat, Sep 19, 2009 at 06:16:25AM CEST: > > It would be nice if there was an option to tell automake not to (do > > 'uninstall' as part of distcheck | require tha

Re: distcheck and uninstall

On Sat, 2009-09-19 at 08:33 +0200, Ralf Wildenhues wrote: > No, I don't, but automake/NEWS indicates that it should've been around > 1.7, and 'git show Release-1-7:lib/am/distdir.am' looks good, too. Thanks again, Rob signature.asc Description: This is a digitally signed message part

--gnits, AC_INIT and VERSION

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 There was discussion about getting version numbers from VCS recently; I've done a slightly different thing for a while now: AC_DEFUN([SUBUNIT_MAJOR_VERSION], [0]) AC_DEFUN([SUBUNIT_MINOR_VERSION], [0]) AC_DEFUN([SUBUNIT_MICRO_VERSION], [2]) AC_DEFUN([S

Re: place automake files separately from source files

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > This way people can build using the GNU automake system if they so desires > and I do not overwrite the original non-automake Makefiles. Then how can I > specify the sources files in source1,c, etc. Keep in mind that the original > source tree ma

Re: how to detect broken install-sh?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Gough wrote: > Hi, > > I'd like to hear thoughts about the best way to detect a broken install-sh. .. > Maybe it would be good to have a check for problems with install-sh. I think that is a waste of cycles for every project except Automake :).

Re: how to detect broken install-sh?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ralf Wildenhues wrote: What would be the best way? Do you think this might cause other >>> problems? >> I suggest dropping install-sh completely except for the coreutils >> package. > > Expecting GNU coreutils to be installed on each system is unrea

Re: how to detect broken install-sh?

On Sun, 2009-09-27 at 16:00 -0500, Bob Friesenhahn wrote: > On Sun, 27 Sep 2009, Robert Collins wrote: > > > > I suggest dropping install-sh completely except for the coreutils > > package. coreutils is very portable, so its not unreasonable to require > > that it is ins

Re: how to detect broken install-sh?

On Sun, 2009-09-27 at 18:59 -0500, Bob Friesenhahn wrote: > On Mon, 28 Sep 2009, Robert Collins wrote: > > > > The landscape has changed though, and I suspect that if we gather stats > > about this we'll see that install-sh is dead weight for most packages > > ne

Re: how to detect broken install-sh?

On Sun, 2009-09-27 at 20:38 -0500, Bob Friesenhahn wrote: > > Thats the key number - the amount of benefit that install-sh gives you. > > This violates a core principle of GNU in that "benefits" should be for > the benefit of the recipients of the software rather than for the for > the develope

Re: how to detect broken install-sh?

On Mon, 2009-09-28 at 08:56 +0200, Ralf Wildenhues wrote: > > You're much better off arguing that packages update to Autoconf 2.64, > in many cases the configure script will shrink by more than 15K over > the one generated by 2.63 (and it'll be a bit faster, too). Nice! - and I think they should

Re: Non-recursive automake

On Sat, 2009-10-17 at 20:09 -0500, Bob Friesenhahn wrote: > > I complained about this perhaps five years ago since it is the most > annoying issue related to non-recursive build. There was some > discussion on this list at that time but nothing was done to make > things better. > > It seems t

Re: Non-recursive automake

On Sun, 2009-10-18 at 08:39 +0200, Ralf Wildenhues wrote: > > http://sources.redhat.com/ml/automake/2001-08/msg00112.html > > > > This added a new directive 'subdir_include' which does an include but > > adjusts all the paths in the make/automake rules in the included > > fragment to the relative

Re: --gnits, AC_INIT and VERSION

On Sun, 2009-11-29 at 22:10 +0100, Ralf Wildenhues wrote: > Hello Robert, and sorry for not replying on this earlier: Hi - no problems ;). > * Robert Collins wrote on Wed, Sep 23, 2009 at 10:03:42AM CEST: > > There was discussion about getting version numbers from VCS recently; >

Re: Autotools GSoC ideas

On Tue, Mar 8, 2011 at 1:10 AM, Ralf Wildenhues wrote: > Hello, > > I'll throw a couple of suggestions for Autotools out there: > > 1) Interfacing with the Test Anything Protocol (TAP) (or maybe another > test protocol?).  Automake-generated Makefiles could be consumers of the > protocol for third

Re: Autotools GSoC ideas

On Wed, Mar 9, 2011 at 8:39 AM, Stefano Lattarini wrote: > I don't know how the GSoC proposals are evaluated, but if reviewers tend > to prefer more precise goals, extending the proposal in this way might > not be a smart move.  Maybe something like the following would be better? > >  ``Interfacin

Re: [GSoC Proposal] automake - Interfacing with a test protocol like TAP or subunit

On Sat, Mar 19, 2011 at 1:03 PM, Stefano Lattarini wrote: > ABSTRACT: > >  The Test Anything Protocol (TAP) is a simple text-based protocol >  that allows communication between test scripts and a test harness. ... > Now, in all honesty, I must say that I've chosen TAP not only for its > objective

Re: [GSoC Proposal] automake - Interfacing with a test protocol like TAP or subunit

On Sun, Mar 20, 2011 at 8:53 PM, Ralf Wildenhues wrote: > Hi Robert, > > thanks for the feedback.  I have a couple of questions: > > * Robert Collins wrote on Sun, Mar 20, 2011 at 05:10:16AM CET: >> TAP is an extremely simple protocol, and the extensions to it to >&

Re: [GSoC Proposal] automake - Interfacing with a test protocol like TAP or subunit

On Sun, Mar 20, 2011 at 10:01 PM, Stefano Lattarini wrote: > Hello Robert, and thanks for the feedback. > > On Sunday 20 March 2011, Robert Collins wrote: >> On Sat, Mar 19, 2011 at 1:03 PM, Stefano Lattarini >> wrote: >> > ABSTRACT: >> > >> >  T

Re: [GSoC Proposal] automake - Interfacing with a test protocol like TAP or subunit

On Tue, Mar 22, 2011 at 8:41 AM, Stefano Lattarini > to its suboptimal documentation.  So I'm going to ask: Robert, as > the main proposer/supporter of the SubUnit protocol here, would you > be willing and ready to help me out during my prospective work with > GSoC, if I update my application's goa

Re: ok, new libtool for cygwin updates

Thanks edward, when I started looking into those, I read somewhere in the automake pages, that the XFAIL results, are "expected fails", so only the FAIL: pr87.test FAIL: subdirbuiltsources.test Still need to be looked at. Sorry for the slight misdirection. Rob - Original Message -

Re: ok, new libtool for cygwin updates

-- Original Message - From: "Robert Collins" <[EMAIL PROTECTED]> To: "edward" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Sunday, March 11, 2001 2:01 AM Subject: Re: ok, new libtool for cygwin updates > Thanks edward, >

Re: ok, new libtool for cygwin updates

- Original Message - From: "edward" <[EMAIL PROTECTED]> To: "Akim Demaille" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, March 12, 2001 11:51 PM Subject: Re: ok, new libtool for cygwin updates > > - Original Message - > From: "Akim Demaille" <[EMAIL PROTECTED]> > To:

pr19.test

Hi, I've altered pr19.test to be (added VERBOSE=yes, and AC_EXEEXT && AC_OBJEXT). I've tried this test on both openBSD & windows. It's failing on both (unaltered on openBSD as it doesn't have the .exe headache). I'm quite happy to commit some time to troubleshooting this, if you folk want to

Re: pr19.test

est === 1 of 1 tests failed === make[1]: *** [check-TESTS] Error 1 make[1]: Leaving directory `/usr/src/automake/tests' make: *** [check-am] Error 2 - Original Message - From: "edward" <[EMAIL PROTECTED]> To: "Robert Collins" <[EM

RE: ok, new libtool for cygwin updates

andre Oliva [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, March 13, 2001 5:12 PM > To: Robert Collins > Cc: edward; Akim Demaille; [EMAIL PROTECTED] > Subject: Re: ok, new libtool for cygwin updates > > > On Mar 12, 2001, "Robert Collins" > <[EMAIL PROTECTED]> wrote:

RE: ok, new libtool for cygwin updates

point for things cygwin. (And those two tests fail on cygwin as well).. Rob > -Original Message- > From: Alexandre Oliva [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, March 13, 2001 6:12 PM > To: Robert Collins > Cc: edward; Akim Demaille; [EMAIL PROTECTED] > Subject: Re: ok,

Re: pr19.test

Right, I reset my automake dir to CVS no patches, test log in testSubDir (running on cygwin 1.1.8-2)=== $ perl -pi.old -e 's/^\t\@/\t/g' Makefile $ make distdir chmod -R a+w ./am_lex_bug-0.1.1 >/dev/null 2>&1; rm -rf ./am_lex_bug-0.1.1 mkdir ./am_lex_bug-0.1.1 for file in Makefile.am Makef

possible bug..

In a Makefile.am I have (abriged) noinst_PROGRAMS = cf_gen cfgen_SOURCES = cf_gen.c cf_gen_defines.h cfgen_LDADD = ../lib/libmiscutil.a but when I run automake I get src/Makefile.am:22: invalid unused variable name: `cfgen_LDADD' src/Makefile.am:20: invalid unused variable name: `cfgen_SOURCE

Re: possible bug..

- Original Message - From: "Akim Demaille" <[EMAIL PROTECTED]> To: "Robert Collins" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, March 26, 2001 7:13 PM Subject: Re: possible bug.. > > | In a Makefile.am I have (abriged) > |

2nd possibly silly question: XTRA_foo_SOURCES

I several warnings of the form : src/Makefile.am:42: squid_SOURCES includes configure substitution `@DNS_SOURCE@' for a makefile.am containing (trimmed for clarity): EXTRA_squid_SOURCES = dns.c dns_internal.c squid_SOURCES = \ access_log.c acl.c asn.c auth_modules.c authenticate.c cache_cf.c c

Feature request.

I haven't dug into automakes internals.. or I'd consider hacking this up myself. It seems to me that a useful feature would be a DEFINES primary that allows extra DEFINES on a per program basis. i.e (drawing on a similar example in the documentation) instead of bin_PROGRAMS = etags ctags ctags_SO

Re: Feature request.

- Original Message - From: "Akim Demaille" <[EMAIL PROTECTED]> To: "Robert Collins" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, March 26, 2001 9:11 PM Subject: Re: Feature request. > > | I haven't dug into automakes inter

possible bug with depcomp

The project I'm converting to automake uses AC_CONFIG_AUX_DIR(cfgaux). The dependency cehcking code was looking for depend in the srcdir, not the srcdir/cfgaux. I'm using a cvs version of autoconf - it's possible they've changed the variables used... Anyway, I've worked around it by dnl'ing the A

program target missing $(EXEEXT)

I hope I'm sending these problem reports to the right place... Environment: cygwin. (Bleeding edge custom build). I'm using automake CVS (updated around 2 hours ago). The following makefile.am == bin_PROGRAMS = client == generates the following target list (abridged) in Makefile.in == client: $(

Re: program target missing $(EXEEXT)

AC_EXEEXT was already present. I added AC_OBJEXT and ran automake --foreign again, no change. Rob - Original Message - From: "Akim Demaille" <[EMAIL PROTECTED]> To: "Robert Collins" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, March

Re: program target missing $(EXEEXT)

- Original Message - From: "Akim Demaille" <[EMAIL PROTECTED]> To: "Robert Collins" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, March 26, 2001 11:03 PM Subject: Re: program target missing $(EXEEXT) > >>>>> "Rob

RE: program target missing $(EXEEXT)

Edward, I recall a discussion on your patch where it wasn't accepted - which is why I brought the topic with a frest start. Rob > -Original Message- > From: edward [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, March 27, 2001 11:00 AM > To: Robert Collins; Akim Dema

Re: Help with CVS (Was: Conditionals in CVS Automake)

- Original Message - From: <[EMAIL PROTECTED]> To: "Robert Boehne" <[EMAIL PROTECTED]> Cc: "Akim Demaille" <[EMAIL PROTECTED]>; "Lars J. Aas" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, March 28, 2001 7:27 AM Subject: Re: Help with CVS (Was: Conditionals in CVS Automake) >

RE: program target missing $(EXEEXT)

> -Original Message- > From: edward [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, March 28, 2001 11:27 AM > To: Robert Collins; Akim Demaille > Cc: [EMAIL PROTECTED] > Subject: Re: program target missing $(EXEEXT) > > > yep. enclosed is a patch which demons

RE: program target missing $(EXEEXT)

> -Original Message- > From: edward [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, March 28, 2001 12:47 PM > To: Robert Collins; Akim Demaille > Cc: [EMAIL PROTECTED] > Subject: Re: program target missing $(EXEEXT) > > > here is the current situation as i

Fw: 2nd possibly silly question: XTRA_foo_SOURCES

I assume this got overlooked? Or maybe I missed any reply... Any suggestions as to what I'm doing wrong? Rob - Original Message - From: "Robert Collins" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, March 26, 2001 8:04 PM Subject:

Re: Fw: 2nd possibly silly question: XTRA_foo_SOURCES

- Original Message - From: "Lars J. Aas" <[EMAIL PROTECTED]> To: "Robert Collins" <[EMAIL PROTECTED]> Sent: Saturday, March 31, 2001 11:10 PM Subject: Re: Fw: 2nd possibly silly question: XTRA_foo_SOURCES > On Sat, Mar 31, 2001 at 09:20:14PM +1000,

Re: Fw: 2nd possibly silly question: XTRA_foo_SOURCES

- Original Message - From: "edward" <[EMAIL PROTECTED]> To: "Robert Collins" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Sunday, April 01, 2001 2:44 AM Subject: Re: Fw: 2nd possibly silly question: XTRA_foo_SOURCES > Robert, > > Tr

Re: Fw: 2nd possibly silly question: XTRA_foo_SOURCES

- Original Message - From: "Lars J. Aas" <[EMAIL PROTECTED]> To: "Robert Collins" <[EMAIL PROTECTED]> Sent: Sunday, April 01, 2001 1:20 AM Subject: Re: Fw: 2nd possibly silly question: XTRA_foo_SOURCES > On Sun, Apr 01, 2001 at 12:19:44AM +1000, Rober

make dist and BUILT_SOURCES

Yet another question from the newbie. I have a number of built source (.hand .c) files that are built from other soources/configure settings. "make dist" is failing to find these files. (Some of them shouldn't be included in the distribution, and some can be). is there some way to exclude speci

make dist and sources in subdirs

I have three questions: 1) Based on a recent comment on this list, I have noinst_LIBRARIES = libfoo.a lib_foo_a_SOURCES = foo/a.c foo/b.c foo/c.c upon entering this particular directory, make dist does: make[2]: *** No rule to make target `foo.c', needed by `distdir'. Stop. make[2]: Leaving di

Re: make dist and BUILT_SOURCES

- Original Message - From: "Akim Demaille" <[EMAIL PROTECTED]> To: "Robert Collins" <[EMAIL PROTECTED]> Subject: Re: make dist and BUILT_SOURCES > >>>>> "Robert" == Robert Collins <[EMAIL PROTECTED]> writes: > > Ro

Re: make dist and sources in subdirs

- Original Message - From: "Robert Collins" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, April 03, 2001 11:46 PM Subject: make dist and sources in subdirs > I have three questions: > > 1) Based on a recent comment on this list, > I ha

Re: make dist and sources in subdirs

- Original Message - From: "Lars J. Aas" <[EMAIL PROTECTED]> To: "Robert Collins" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Thursday, April 05, 2001 5:34 PM Subject: Re: make dist and sources in subdirs > On Thu, Apr 05, 2001 at 09:20:

Re: make dist and sources in subdirs

- Original Message - From: "Akim Demaille" <[EMAIL PROTECTED]> To: "Alexandre Oliva" <[EMAIL PROTECTED]> Cc: "Robert Collins" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, April 05, 2001 12:56 AM Subject: Re: make dist and

testcase for make dist with subdir SOURCES

The attached test csae demonstrates the problem. I don't think I'll have time to step upto the coding plate, but I figure a the test might make things easier ... :] Rob subobj5.test

Re: make dist and BUILT_SOURCES

- Original Message - From: "Tom Tromey" <[EMAIL PROTECTED]> To: "Akim Demaille" <[EMAIL PROTECTED]> Cc: "Robert Collins" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, April 06, 2001 3:13 AM Subject: Re: make dist and B

Re: program target missing $(EXEEXT)

- Original Message - From: "Akim Demaille" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: "Robert Collins" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, April 06, 2001 3:43 AM Subject: Re: program target missing $(EXEEXT) > >&

  1   2   3   >