On Thu, Jul 7, 2011 at 7:03 AM, Stefano Lattarini
stefano.lattar...@gmail.com 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
Very sorry for the slow response, been EBUSY with real-life.
On Sun, May 22, 2011 at 11:42 PM, Stefano Lattarini
stefano.lattar...@gmail.com 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
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 goal
On Sun, Mar 20, 2011 at 8:53 PM, Ralf Wildenhues ralf.wildenh...@gmx.de 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
support things
On Sun, Mar 20, 2011 at 10:01 PM, Stefano Lattarini
stefano.lattar...@gmail.com 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
stefano.lattar...@gmail.com wrote:
ABSTRACT:
The Test
On Sat, Mar 19, 2011 at 1:03 PM, Stefano Lattarini
stefano.lattar...@gmail.com 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
On Wed, Mar 9, 2011 at 8:39 AM, Stefano Lattarini
stefano.lattar...@gmail.com 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
On Tue, Mar 8, 2011 at 1:10 AM, Ralf Wildenhues ralf.wildenh...@gmx.de 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
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;
I've done
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 path to
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 that a
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 -
-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 :).
-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 unreasonable.
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 installed to locally build and install
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
nearly all of the time.
Maybe the landscape
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 developers of
-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 may
-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])
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 that uninstall leaves no
files behind
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
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
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
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 possible
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)?
It seems
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
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 each
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 not an optimal
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
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 will
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:
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 Cc: the
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 programs
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'
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 $srcdir to
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, but I
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
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 the
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?
that the scripts in lib/ aren't chmodded correctly
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 Perhaps
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 them suitable for a non-recursive
Robert build.
I'm skeptical
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/
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: http://www.robertcollins.net/keys.txt.
signature.asc
Description: This is a
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?
Rob
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
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
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: cannot open /dev/null.tmp: Permission denied
Robert Is this a 'need to use
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 its
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
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: http://www.robertcollins.net/keys.txt.
Index: automake.in
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 doesn't
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 builds with
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
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 bug #, but it's on my todo, waay down
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
much
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 be
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
while
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
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.
/if
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 the default build recipe
though.. I
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_binaries
Can these convenience programs be built
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
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 needs to
be
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 only
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
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
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/:
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 just in
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 compress with compressor 2
Robert clean dist tree
This is the current behavior
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 multiple targets.
IMHO ./configure is not a exactly the right interface to make
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 [
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
want the .gz, I just want the .bz2.
If you are going
===
- 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 and
-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 == Robert Collins [EMAIL PROTECTED] writes:
I looked at this. I
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]
Subject: Re: per object cflags
-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
for
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
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
-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 with g++, not gcc. (this is
for C
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
-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 want
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
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
-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
Robert == Robert Collins
[EMAIL PROTECTED] writes
-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
Robert == Robert Collins
[EMAIL PROTECTED] writes:
Robert
-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
Robert == Robert Collins
[EMAIL PROTECTED] writes
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 pwd`
-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
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
-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 = ...
I have
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
-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 any
-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
-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. We
-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,
Robert == Robert Collins
[EMAIL PROTECTED] writes:
Robert Where
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
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
===
- 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 Collins [EMAIL PROTECTED] writes:
... you end up with `.deps/generic/a.Po'.
The PR asks
===
- 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 sure.
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
1 - 100 of 160 matches
Mail list logo
