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: [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 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: [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 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 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: 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: 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: --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: 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: 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: 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: 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 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 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?

-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?

-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: 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

--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: 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

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

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: 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

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-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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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

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

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

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?

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 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: 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

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

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: 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

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

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

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

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

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: 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

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: 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 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 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: 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: 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: 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 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 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: 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: 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: 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: 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: 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: 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: 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: 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: 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

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: 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

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: 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

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:07 PM > To: Robert Collins > Cc: Tim Waugh; [EMAIL PROTECTED] > Subject: Re: non-recursive project example > > > >>> "Rober

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: 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: 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

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

w/ Automake 1.5, we have the following bug report. In summary, the following shell code: am_aux_dir=`CDPATH=:; cd $ac_aux_dir && pwd` is not portable to MacOS X, and is causing a headache for folk building in the same dir tree. Can we change it to am_aux_dir=`unset CDPATH; cd $ac_aux_dir && p

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

.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: 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 = ...

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

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

  1   2   3   >