make AM_TESTS_ENVIRONMENT='echo RUNNING: "$$f";' check
I added this to the manual as another example of using
[AM_]TESTS_ENVIRONMENT. Closing the bug ... --thanks, karl.
Back on this suggestion ...
It would be very helpful if a new option AM_TESTS_NAME=1
...
RUNNING $name
Looking into it now, I believe this can be done already using
AM_TESTS_ENVIRONMENT (or by an individual user with
TESTS_ENVIRONMENT). The test name is the shell variable $f at
* AM_TESTS_FD_REDIRECT
* AM_TESTS_ENVIRONMENT
* AM_TESTSUITE_SUMMARY_HEADER
(Aside: I see now I should have made that name
AM_TESTS_SUMMARY_HEADER. Oh well, too late now.)
# with AM_TESTS_SHOW_NAME=1
I guess I have nothing against it, for the reasons you give. Can
org>
Subject: Re: bug#49309: Feature Request: Automake script based tests to print
the test name before running it
Am 01.07.2021 um 20:59 schrieb Kasper k:
> Then if some intermittent bad situation happens in
> unattended/disposable CI environment, as an example, then we won't be
>
Am 01.07.2021 um 20:59 schrieb Kasper k:
Then if some intermittent bad situation happens in
unattended/disposable CI environment, as an example, then we won't be
needing to opt into any kind of workaround, it'd be just there right in
the "regular" make-check logs; without introducing crazy
hout introducing crazy
amount of verbosity (which set -x, VERBOSE=1 etc. renders).
/K
From: Peter Johansson
Sent: Thursday, July 1, 2021 1:30 PM
To: Kasper k ; 49...@debbugs.gnu.org
<49...@debbugs.gnu.org>
Subject: Re: bug#49309: Feature Request: Automake script based
Hi Kasper,
I leave to the maintainers to comment on the suggestion, but in the
meantime...
On 1/7/21 1:01 pm, Kasper k wrote:
Hello automake devs,
In script based testsuites
Hello automake devs,
In script based testsuites
(https://www.gnu.org/software/automake/manual/html_node/Scripts_002dbased-Testsuites.html#Scripts_002dbased-Testsuites),
when we run `make check` it prints one of the following string for each test:
PASS , FAIL , XFAIL or SKIP .
However, in
Hi,
We have just launched a site to help existing open source projects
with funding (www.catincan.com). Our goal is to help more open source
projects become self-sustaining and competitive with propriety
solutions. We're hoping you might provide us with some insight by
answering the 3 questions
On Sun, 7 Apr 2013, Boian Mihailov wrote:
Hi,
We have just launched a site to help existing open source projects
with funding (www.catincan.com). Our goal is to help more open source
projects become self-sustaining and competitive with propriety
solutions. We're hoping you might provide us
This seems to serve a similar purpose
http://sfconservancy.org/donate/
run by Bradley M. Kuhn, a FSF board member and someone the Free Software
community knows and trusts.
On Sat, Apr 6, 2013 at 11:05 PM, Boian Mihailov
boian.mihai...@cvalka.comwrote:
Hi,
We have just launched a site to
forcemerge 10697 8031
close 8031
thanks
On 02/13/2011 08:52 PM, Ralf Hemmecke wrote:
This is a copy of
http://lists.gnu.org/archive/html/automake/2011-02/msg00017.html
It's not really a bug, but rather a feature request.
Ralf
Original Message
Subject: slow make clean
On 01/17/2012 10:59 PM, Joel E. Denny wrote:
On Tue, 17 Jan 2012, Jim Meyering wrote:
Below is a patch that adds a --no-cluster option, which I believe does
what Stefano wants. I want it too. OK to push?
Hi Joel,
Thanks. That looks fine, but please adjust the preceding comment
to keep
Package: automake
Version: 1.11.1
'nobase_' is quite a useful prefix when we want to distribute exact
directory structure like it is in our code repository. But its
usefullness is quite dimnished in case of nonrecursive build system
generated by automake. Lets have a look at the example below:
This is a copy of
http://lists.gnu.org/archive/html/automake/2011-02/msg00017.html
It's not really a bug, but rather a feature request.
Ralf
Original Message
Subject: slow make clean
Date: Sat, 12 Feb 2011 23:46:55 +0100
From: Ralf Hemmecke hemme...@gmail.com
To: automake
Hello Luiji,
* Luiji Maryo wrote on Fri, Oct 22, 2010 at 01:51:35AM CEST:
Could you please implement an all-hook? Currently, I have UPX
compress the executable after installation, however I find it would be
much more useful if it were compressed after compilation. Is there a
reason there is
Could you please implement an all-hook? Currently, I have UPX
compress the executable after installation, however I find it would be
much more useful if it were compressed after compilation. Is there a
reason there is no all-hook? Is there an alternative way to do this
(such as some sort of
On Wed, Mar 31, 2010 at 9:04 AM, Manoj Rajagopalan rma...@umich.edu wrote:
A typical use case for me is when one particular function that resides in a
file by itself must be compiled without optimizations so that some
machine-specific numerical information can be calculated accurately. With
Hi,
I am using automake 1.10.1 on KUbuntu 8.04/i686.
I have been using autotools for a while and per-file compilation flags is
something I miss quite often. Would it be possible to introduce this feature
so that each file can be given custom compilation flags if required? For a
target
* Bollinger, John C wrote on Mon, Sep 14, 2009 at 05:33:40PM CEST:
It seems that normally, the generated configure script creates dummy
*.Po files in the right places, thus masking the absence of Make rules
for that purpose. In my case, however, I used Make variables in
Makefile.am to
On Tue, Sep 15, 2009 at 1:33 AM, Bollinger, John C
john.bollin...@stjude.org wrote:
That would also help in the case where one or more $(DEPDIR)s is accidentally
or cluelessly deleted -- the developer would not have to re-run configure
(not an
obvious solution) to fix the project directory.
* Bollinger, John C wrote on Fri, Sep 11, 2009 at 09:09:18PM CEST:
Automake's cross-directory support seems to have at least one serious
problem, however: Makefiles generated by the autotools always build
intermediate objects in the top source directory. For example, if I
am building
[ moving to automake-patches; this is
http://thread.gmane.org/gmane.comp.sysutils.automake.general/9824 ]
* Ralf Wildenhues wrote on Sun, Oct 12, 2008 at 10:46:06PM CEST:
I'll follow up on automake-patches with a patch to test.
Here we go. WDYT?
Cheers,
Ralf
Recursive `include' and
* Akim Demaille wrote on Wed, Sep 24, 2008 at 10:01:01AM CEST:
Le 23 sept. 08 à 23:08, Ralf Wildenhues a écrit :
* Akim Demaille wrote on Tue, Sep 23, 2008 at 04:35:50PM CEST:
I'm slowly getting rid of my recursive Makefiles. Instead I have one
local.mk per directory, and a few Makefile.ams
Le 23 sept. 08 à 23:08, Ralf Wildenhues a écrit :
Hi Akim,
Hi Ralf!
* Akim Demaille wrote on Tue, Sep 23, 2008 at 04:35:50PM CEST:
I'm slowly getting rid of my recursive Makefiles. Instead I have one
local.mk per directory, and a few Makefile.ams that include them. Of
course I have to
Ralf Wildenhues [EMAIL PROTECTED] writes:
* Akim Demaille wrote on Tue, Sep 23, 2008 at 04:35:50PM CEST:
I'm slowly getting rid of my recursive Makefiles. Instead I have one
local.mk per directory, and a few Makefile.ams that include them. Of
course I have to prefix all my file names
Hi Ben,
* Ben Pfaff wrote on Wed, Sep 24, 2008 at 06:51:14PM CEST:
Ralf Wildenhues [EMAIL PROTECTED] writes:
I'd really hate to invade make's namespace. They may come up with this
really cool new makefile variable, and we can't use it then. :-/
I wonder whether this is a real issue,
Hi friends!
I have a suggestion.
I'm slowly getting rid of my recursive Makefiles. Instead I have one
local.mk per directory, and a few Makefile.ams that include them. Of
course I have to prefix all my file names with the name of the
directory, and I find that this explicit name is
Hi Akim,
* Akim Demaille wrote on Tue, Sep 23, 2008 at 04:35:50PM CEST:
I'm slowly getting rid of my recursive Makefiles. Instead I have one
local.mk per directory, and a few Makefile.ams that include them. Of
course I have to prefix all my file names with the name of the
directory,
Hi,
I am using the libsndfile package in my program as a library for
conditional static linking. The official release is broken with regard
to FLAC support because the FLAC api changed, so I have patched it (I
submitted the patches to the developer, but he isn't interested). This
works
I always try to write nonrecursive makefiles. But now I'm working on
a project that has several trees of files that all need to go to
different places, while preserving their relative hierarchy. For
example I have $(top_srcdir)/www/cgi-bin/* that needs to go to
$(cgidir), and
Hi Ben,
* Ben Elliston wrote on Wed, Mar 09, 2005 at 03:41:46AM CET:
I approached the Libtool maintainers with this request, who convinced
me that Automake was the right place to implement this. I would like
Automake-generated Makefiles to pass --quiet to libtool when make is
invoked with
Hi Ralf
Either use
make -s LIBTOOLFLAGS=--silent
or
configure LIBTOOLFLAGS=--silent
or some nice hack to enable this automatically in configure.ac
mentioned in the discussion at that time[1].
Thanks. That's probably good enough.
Cheers, Ben
signature.asc
Description: OpenPGP digital
I approached the Libtool maintainers with this request, who convinced me that
Automake was the right place to implement this. I would like Automake-generated
Makefiles to pass --quiet to libtool when make is invoked with -s.
At present, even when compiling with make -s, libtool echoes the
Hello!
Please CC me, as I'm not subscribed on this list.
I wanna have support for splint / lint during compile.
I imagine it in the following way:
I add a line to configure.in / configure.ac
AM_PROG_LINT(lint options)
and that's it from the user point of view.
The configure script checks
Albert Chin [EMAIL PROTECTED] writes:
When building software with installable .m4 files (libtool, pkgconfig,
gtk+, etc.), if each software program is installed to a separate
directory, aclocal must be used like so:
$ aclocal -I [path to libtool .m4 files] \
-I [path to pkgconfig .m4
On Fri, Sep 17, 2004 at 10:50:09AM +0200, Andreas Schwab wrote:
Albert Chin [EMAIL PROTECTED] writes:
When building software with installable .m4 files (libtool, pkgconfig,
gtk+, etc.), if each software program is installed to a separate
directory, aclocal must be used like so:
$
Hi Albert,
Albert Chin wrote:
On Fri, Sep 17, 2004 at 10:50:09AM +0200, Andreas Schwab wrote:
Albert Chin [EMAIL PROTECTED] writes:
When building software with installable .m4 files (libtool, pkgconfig,
gtk+, etc.), if each software program is installed to a separate
directory, aclocal must
On Fri, Sep 17, 2004 at 02:49:05PM +0100, Gary V. Vaughan wrote:
It may be small consolation, but the next release of GNU m4 has the last
bit of functionality required to eliminate aclocal entirely.
How does it do that? If the .m4 files for libtool 1.4 are in
/opt/libtool14 and the .m4 files
Albert Chin wrote:
On Fri, Sep 17, 2004 at 02:49:05PM +0100, Gary V. Vaughan wrote:
It may be small consolation, but the next release of GNU m4 has the last
bit of functionality required to eliminate aclocal entirely.
How does it do that? If the .m4 files for libtool 1.4 are in
When building software with installable .m4 files (libtool, pkgconfig,
gtk+, etc.), if each software program is installed to a separate
directory, aclocal must be used like so:
$ aclocal -I [path to libtool .m4 files] \
-I [path to pkgconfig .m4 files] ...
How about an environment variable
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Mar 03, 2004 at 09:18:49AM -0500, Hans Deragon wrote:
Eric Siegerman wrote:
On Tue, Mar 02, 2004 at 08:34:19AM -0600, Bob Friesenhahn wrote:
[...]
What if we reckognize some directories as to be never deleted? For
instance, /, /usr/bin,
On Thu, 4 Mar 2004, Andrew Suffield wrote:
Thus, if I'm right that Automake doesn't know which directories
the package owns, it should should err on the side of caution: it
should *not* try to delete any empty directories at uninstall
time. Neither should Automake try to guess -- guesses
Hans == Hans Deragon [EMAIL PROTECTED] writes:
HansAutomake should create a script that simply contains all the rm
Hanscommands and have it installed with the other binaries.
You could write a program to do this, if you wanted to experiment
with it. You would run `make -n uninstall'
On Wed, 3 Mar 2004, Bob Friesenhahn wrote:
The reason why I mentioned /usr/local is because it is a shared
directory. I could also have mentioned /usr. While it seems nice for
a package to 100% clean-up after itself, a bug could cause the package
uninstall to accidentally remove the
,-- On Wed, 3 Mar, Bob Friesenhahn wrote:
[...]
| It is not always easy to see if a directory is empty. For example,
| when NFS is being used, sometimes .nfs files are created in the
| directories, so the directory is not really empty.
Won't remove commands refuse to clean up a directory if
On Tue, Mar 02, 2004 at 05:00:14PM -0500, Eric Siegerman wrote:
On Tue, Mar 02, 2004 at 08:34:19AM -0600, Bob Friesenhahn wrote:
If a package supports creating the directory /usr/local (as Automake
does by default) should this directory be recursively removed if a
package is uninstalled?
Daniel Reed wrote:
On 2004-03-02T08:34-0600, Bob Friesenhahn wrote:
) On Mon, 1 Mar 2004, Hans Deragon wrote:
) When performing a make uninstall, I notice that it only deletes the files,
) not the empty directories. It would be nice that after removing a file, it
) removes all the empty
Eric Siegerman wrote:
On Tue, Mar 02, 2004 at 08:34:19AM -0600, Bob Friesenhahn wrote:
If a package supports creating the directory /usr/local (as Automake
does by default) should this directory be recursively removed if a
package is uninstalled?
Absolutely not! (I rather suspect the question
On Tue, 2 Mar 2004, Daniel Reed wrote:
On 2004-03-02T08:34-0600, Bob Friesenhahn wrote:
) On Mon, 1 Mar 2004, Hans Deragon wrote:
) When performing a make uninstall, I notice that it only deletes the files,
) not the empty directories. It would be nice that after removing a file, it
)
On Tue, Mar 02, 2004 at 08:34:19AM -0600, Bob Friesenhahn wrote:
If a package supports creating the directory /usr/local (as Automake
does by default) should this directory be recursively removed if a
package is uninstalled?
Absolutely not! (I rather suspect the question was rhetorical,
but
On Mon, 1 Mar 2004, Hans Deragon wrote:
When performing a make uninstall, I notice that it only deletes the files,
not the empty directories. It would be nice that after removing a file, it
removes all the empty directories recursively. For example:
If a package supports creating the
On 2004-03-02T08:34-0600, Bob Friesenhahn wrote:
) On Mon, 1 Mar 2004, Hans Deragon wrote:
) When performing a make uninstall, I notice that it only deletes the files,
) not the empty directories. It would be nice that after removing a file, it
) removes all the empty directories
Hi!
Though I appreciate the automatic dependency tracking mechanism,
I sometimes encounter problems with this approach using Intel's C++
compiler. For reasons I do not understand prefixed objects get rebuilt,
so either depcomp cannot properly deal with Intel's Compiler (which is
handled as if it
On Mon, Jul 28, 2003 at 01:09:21PM +0200, Markus Werle wrote:
Hi!
Though I appreciate the automatic dependency tracking mechanism,
I sometimes encounter problems with this approach using Intel's C++
compiler. For reasons I do not understand prefixed objects get rebuilt,
so either depcomp
Alexandre Duret-Lutz wrote:
On Mon, Jul 28, 2003 at 01:09:21PM +0200, Markus Werle wrote:
Hi!
Though I appreciate the automatic dependency tracking mechanism,
I sometimes encounter problems with this approach using Intel's C++
compiler. For reasons I do not understand prefixed objects
On Mon, 2002-05-06 at 06:30, Tom Tromey wrote:
Nowadays we could probably implement pattern rules purely in automake.
Back in the old days we didn't have the machinery to allow this.
Automake itself was too primitive. But now it would be more possible,
if someone were motivated. Maybe this
Am Die, 2002-05-07 um 10.26 schrieb Alex Hornby:
On Mon, 2002-05-06 at 06:30, Tom Tromey wrote:
Nowadays we could probably implement pattern rules purely in automake.
Back in the old days we didn't have the machinery to allow this.
Automake itself was too primitive. But now it would be
Alex == Alex Hornby [EMAIL PROTECTED] writes:
[...]
Alex Certainly would. The problem I had with suffix rules, was that one
Alex invocation of the idl compiler on one .idl file expands into many .h and
Alex .cpp files, therefore I needed a suffix rule for each product. So far so
Alex good,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Monday 06 May 2002 07:29, Tom Tromey wrote:
Christoph == [EMAIL PROTECTED] writes:
Christoph Yes and no. Take the example of QT's moc files. They have
Christoph to be generated from .h files, if the class defined in the
Christoph .h file
Tom Tromey wrote:
Alex == Alex Hornby [EMAIL PROTECTED] writes:
Alex I suppose automake could be enhanced so that it automatically
Alex knew which files are BUILT_SOURCES by looking back through the
Alex suffix rules. Then the small overhead of listing them twice
Alex would be removed.
Alex == Alex Hornby [EMAIL PROTECTED] writes:
Alex I suppose automake could be enhanced so that it automatically
Alex knew which files are BUILT_SOURCES by looking back through the
Alex suffix rules. Then the small overhead of listing them twice
Alex would be removed.
BUILT_SOURCES are built
Christoph == [EMAIL PROTECTED] writes:
Christoph Yes and no. Take the example of QT's moc files. They have
Christoph to be generated from .h files, if the class defined in the
Christoph .h file does mention a Q_OBJECT macro. I would love to have
Christoph something in my Makefiles which greps
Alex == Alex Hornby [EMAIL PROTECTED] writes:
Alex Suffix rules should be portable to all makes, its pattern rules
Alex that aren't available everywhere.
Nowadays we could probably implement pattern rules purely in automake.
Back in the old days we didn't have the machinery to allow this.
It is common style to generate c/cpp source files from some meta-languages.
Examples are lex, yacc, QT's moc, swig, and probably many other tools. AFAIK
there is currently no way to handle such files in automake and the recommended
way is to write scripts editing Makefile.in's to add seperate
On Mon, 2002-04-29 at 10:24, [EMAIL PROTECTED]
wrote:
It is common style to generate c/cpp source files from some meta-languages.
Examples are lex, yacc, QT's moc, swig, and probably many other tools. AFAIK
there is currently no way to handle such files in automake and the recommended
way
alex I think the recommended way is to add suffix rules to produce the built
alex sources, not edit the Makefile.ins.
But is this really portable ? I looked at automake 1.4 info pages, and it tells
something about GNU make:
Handling new file extensions
It is
On Mon, 2002-04-29 at 12:24, [EMAIL PROTECTED]
wrote:
alex I think the recommended way is to add suffix rules to produce the built
alex sources, not edit the Makefile.ins.
But is this really portable ? I looked at automake 1.4 info pages, and it tells
something about GNU make:
Suffix
alex Could you check if the automake 1.6.x docs make the same reference to
alex GNU make instead of just make when talking about suffix rules?
No, they don't.
So this is enough if you have a special file type from which source files
should
be generated. But the moc problem isn't solved
On Mon, 2002-04-29 at 12:44, [EMAIL PROTECTED]
wrote:
alex Could you check if the automake 1.6.x docs make the same reference to
alex GNU make instead of just make when talking about suffix rules?
No, they don't.
Great, so no doco patch needed :)
So this is enough if you have a special
| 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 =
- 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 internals.. or I'd consider hacking
this up
72 matches
Mail list logo
