On 2/6/25 17:42, Karl Berry wrote:
Unsetting it in the shell test driver could work,
Yep. That's what I had in mind, sorry I wasn't clear.
to the line that actually executes the Perl script
The t/parallel-tests-log-compiler-example.sh test (copied below) is
testing Automake tests, so
Unsetting it in the shell test driver could work,
Yep. That's what I had in mind, sorry I wasn't clear.
to the line that actually executes the Perl script
The t/parallel-tests-log-compiler-example.sh test (copied below) is
testing Automake tests, so the script is not invoked directly, b
On 2/5/25 16:18, Karl Berry wrote:
Hi Jacob,
If a plain "use warnings;" in a script overrides setting
PERL5OPT=-Mwarnings=FATAL,all in the environment,
Fortunately, it was my mistake. I got confused in the testing I was
doing. use warnings; in a script does not override that PERL5OPT
Hi Jacob,
If a plain "use warnings;" in a script overrides setting
PERL5OPT=-Mwarnings=FATAL,all in the environment,
Fortunately, it was my mistake. I got confused in the testing I was
doing. use warnings; in a script does not override that PERL5OPT
setting. I'll fix the intentional w
On 2/4/25 17:56, Karl Berry wrote:
If the concern is making certain that new Perl warnings are noticed,
simply putting PERL5OPT='-Mwarnings=FATAL,all' in the environment when
running the testsuite should accomplish that.
Thanks for the suggestion. I put a note into HACKING about i
If the concern is making certain that new Perl warnings are noticed,
simply putting PERL5OPT='-Mwarnings=FATAL,all' in the environment when
running the testsuite should accomplish that.
Thanks for the suggestion. I put a note into HACKING about it.
I also tried running the tests tha
On 2/1/25 16:23, Karl Berry wrote:
I have to admit I don't much like any method Jacob mentioned, or
anything else I can think of (sed ...) to munge core source files.
I don't know about the past, but I've never knowingly ignored a Perl
warning that's been reported or that I've seen. Going to the
I have to admit I don't much like any method Jacob mentioned, or
anything else I can think of (sed ...) to munge core source files.
I don't know about the past, but I've never knowingly ignored a Perl
warning that's been reported or that I've seen. Going to these lengths
to have fatal warnings in
On 1/31/25 13:34, Zack Weinberg wrote:
[...]
There was actually a concrete reason why I put FATAL => 'all' in there:
I wanted it to be a hard error *during development* when new Perl warnings
show up, so that they get fixed promptly rather than going neglected,
trickling into releases, and spammi
On 1/31/25 11:22, Karl Berry wrote:
Maybe Automake shouldn't use:
use warnings FATAL => 'all';
Changed to just "use warnings;", as Jacob also noted.
I also took the opportunity to systematize on
use 5.006; use strict; use warnings;
all on one line to reduce real estate usage.
On Fri, Jan 31, 2025, at 12:22 PM, Karl Berry wrote:
> Maybe Automake shouldn't use:
> use warnings FATAL => 'all';
>
> Changed to just "use warnings;", as Jacob also noted.
>
> I also took the opportunity to systematize on
> use 5.006; use strict; use warnings;
> all on one line to reduc
Maybe Automake shouldn't use:
use warnings FATAL => 'all';
Changed to just "use warnings;", as Jacob also noted.
I also took the opportunity to systematize on
use 5.006; use strict; use warnings;
all on one line to reduce real estate usage.
Not all files use 5.006, and I'd be a bit
On 1/30/25 17:52, Karl Berry wrote:
[...]
Maybe Automake shouldn't use:
use warnings FATAL => 'all';
Agreed. I'm working on it. --thanks, karl.
Using "use warnings;" (and "use strict;") is good style in Perl,
however. The best option is probably to just delete the "FATAL =>
'a
There is no plan. But I guess this gratuitously-induced problem is bad
enough that we had better do something sooner rather than later. Since
it's the Perl development release and not the stable release, it doesn't
seem totally urgent. In any case, I expect to be tied up with other
thi
Igor Todorovski writes:
> This is the relevant code:
>
> return (!!$val == $neg) ? '##%' : '';
I've attached a patch that fixes this by quoting $val and the '!'
operators.
Maybe Automake shouldn't use:
use warnings FATAL => 'all';
As was mentioned in the GitHub thread you linked and Per
5 at 10:16 PM
To: Igor Todorovski
Cc: automake@gnu.org
Subject: [EXTERNAL] Re: automake-1.17 fails with latest Perl (5.41.8) -
Possible precedence problem between ! and numeric eq (==)
Igor Todorovski writes:
> This is the relevant code:
>
> return (!!$val == $neg) ? '##%' :
precedence
problem between ! and numeric eq (==)
With the latest version of Perl (Perl 5.41.8), automake 1.17 exits due to an
error:
./bin/automake-1.17 ; echo $?
Possible precedence problem between ! and numeric eq (==) at
./bin/automake-1.17 line 6875.
255
This is the relevant code
With the latest version of Perl (Perl 5.41.8), automake 1.17 exits due to an
error:
./bin/automake-1.17 ; echo $?
Possible precedence problem between ! and numeric eq (==) at
./bin/automake-1.17 line 6875.
255
This is the relevant code:
return (!!$val == $neg) ? '##%' : '';
e.From 713d9822bbfb2923115065efaefed34a0113f8a1 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Sat, 1 Apr 2023 16:44:03 -0700
Subject: [PATCH] Fix timing bug on high-speed builds
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Problem reported by Bogdan via Jacob Bachmeyer in:
Jacob Bachmeyer , Sat Apr 01 2023 04:54:22
GMT+0200 (Central European Summer Time)
A quick introduction to the situation for the Autoconf list:
The Automake maintainers have encountered a bizarre issue with
sporadic random test failures, seemingly due to "disk writes not
taking effect" (as Kar
A quick introduction to the situation for the Autoconf list:
The Automake maintainers have encountered a bizarre issue with sporadic
random test failures, seemingly due to "disk writes not taking effect"
(as Karl Berry mentioned when starting the thread). Bogdan appears to
have traced the iss
Hi,
On 2022-08-01, aotto wrote:
> but in ONE library I dont want to have a static library build because it
> is only used as dlopen (by tcl)…
[...]
> pkglib_LTLIBRARIES = libtclmkkernel.la
[...]
> question what I have to-do to avoid a "static" library "libtclmkkernel.a"
Since this seems to be a
Hi,
my build uses "LT_INIT([dlopen disable-static])" and compile a lot of
libraries by default only shared.
if I "configure" with "--enable-static" the automake/libtool create the
static libraries to → everything ok.
but in ONE library I dont want to have a static library build because it
Hi Thomas
I'm seeing a similar (but not identical) issue[1] which is also
related to the subdir-objects commit[2] when building the package
"Heimdal" with automake-1.16+ (and GNU make-4.2.1).
Making all in hcrypto
make[2]: Entering directory
'/home/abuild/rpmbuild/BUILD/heimdal-7.5.0/lib/hcrypto'
Am 25.08.19 um 00:03 schrieb Assaf Gordon:
Issue solved!
Thanks to Bruno Haible in
https://lists.gnu.org/r/bug-gnulib/2019-08/msg00064.html
Quoting that message (and my reply):
---
On 2019-08-24 3:36 p.m., Bruno Haible wrote:
I think the problem is that 'bmake' does not co
On Sat, 24 Aug 2019, Assaf Gordon wrote:
Hello Bob,
On 2019-08-24 5:26 p.m., Bob Friesenhahn wrote:
On Sat, 24 Aug 2019, Assaf Gordon wrote:
hello_LDADD = $(top_builddir)/lib/lib$(PACKAGE).a
datamash_LDADD = $(top_builddir)/lib/lib$(PACKAGE).a
This seems like a bug in those two packages.
Hello Bob,
On 2019-08-24 5:26 p.m., Bob Friesenhahn wrote:
On Sat, 24 Aug 2019, Assaf Gordon wrote:
hello_LDADD = $(top_builddir)/lib/lib$(PACKAGE).a
datamash_LDADD = $(top_builddir)/lib/lib$(PACKAGE).a
This seems like a bug in those two packages. It should never be
desirable to refer to
On Sat, 24 Aug 2019, Assaf Gordon wrote:
And indeed,
GNU hello and GNU datamash (which exhibit the problem)
have something like this in their Makefile.am:
hello_LDADD = $(top_builddir)/lib/lib$(PACKAGE).a
datamash_LDADD = $(top_builddir)/lib/lib$(PACKAGE).a
While sed and coreutils (which
Assaf Gordon writes:
> Issue solved!
>
> Thanks to Bruno Haible in
> https://lists.gnu.org/r/bug-gnulib/2019-08/msg00064.html
>
> Quoting that message (and my reply):
> ---
> On 2019-08-24 3:36 p.m., Bruno Haible wrote:
>> I think the problem is that 'b
Issue solved!
Thanks to Bruno Haible in
https://lists.gnu.org/r/bug-gnulib/2019-08/msg00064.html
Quoting that message (and my reply):
---
On 2019-08-24 3:36 p.m., Bruno Haible wrote:
I think the problem is that 'bmake' does not consider the targets
'foo' and '
Hello Mathieu, Karl,
On 2019-08-24 11:43 a.m., Mathieu Lirzin wrote:
On Sat, 24 Aug 2019, Assaf Gordon wrote:
I've encountered a problem where a released tarball (of 'make dist')
generated by Automake-1.16.1 fails to build with non-gnu make (e.g.
"bmake" on BSDs).
T
Hello Assaf,
Assaf Gordon writes:
> On 2019-08-24 7:34 a.m., Bob Friesenhahn wrote:
>> On Sat, 24 Aug 2019, Assaf Gordon wrote:
>
>>>
>>> I've encountered a problem where a released tarball (of 'make dist')
>>> generated by Automake-1.16.1
On 2019-08-24 7:34 a.m., Bob Friesenhahn wrote:
On Sat, 24 Aug 2019, Assaf Gordon wrote:
I've encountered a problem where a released tarball (of 'make dist')
generated by Automake-1.16.1 fails to build with non-gnu make (e.g.
"bmake" on BSDs).
The exact same pro
On Sat, 24 Aug 2019, Assaf Gordon wrote:
Hello,
I've encountered a problem where a released tarball (of 'make dist')
generated by Automake-1.16.1 fails to build with non-gnu make (e.g.
"bmake" on BSDs).
The exact same project and 'make dist' with automake-1.1
Hello,
I've encountered a problem where a released tarball (of 'make dist')
generated by Automake-1.16.1 fails to build with non-gnu make (e.g.
"bmake" on BSDs).
The exact same project and 'make dist' with automake-1.15 builds fine.
It has something to do wi
On 09/03/2018 10:35 AM, Thomas Dickey wrote:
On Mon, Sep 03, 2018 at 09:13:13AM -0500, Eric Blake wrote:
...
Note that the most recent version of 'install-sh' as installed by Automake
states:
# Copyright (C) 1994 X Consortium
looking at my collection of untarred X sources, there's an issue wit
On 09/03/2018 01:24 PM, Paul Eggert wrote:
Mathieu Lirzin wrote:
According to ‘git blame’ I appear to not have touch this file, so if you
think that I am eligible, I am volunteering on this rewriting task.
Thanks for volunteering.
Indeed, and I think you are reasonably safe for the task.
E
- Original Message -
| From: "Thomas Dickey"
| To: "Paul Eggert"
| Cc: "Mathieu Lirzin" , "Eric Blake" ,
"bug-autoconf" , "automake"
|
| Sent: Monday, September 3, 2018 5:11:43 PM
| Subject: Re: copyright problem with install-
- Original Message -
| From: "Paul Eggert"
| To: "Mathieu Lirzin" , "Eric Blake"
| Cc: bug-autoc...@gnu.org, "automake"
| Sent: Monday, September 3, 2018 2:24:32 PM
| Subject: Re: copyright problem with install-sh, request for clean-room rewrite
Mathieu Lirzin wrote:
According to ‘git blame’ I appear to not have touch this file, so if you
think that I am eligible, I am volunteering on this rewriting task.
Thanks for volunteering. Eric, do you think it would save time overall if you
sent him the part of install-sh that you are sure is
Hello Eric,
Eric Blake writes:
> This is contradictory, and needs to be fixed in the Autoconf
> manual. However, the question on the floor is whether the fix is
> merely rewording that sentence to describe the actual copyright and
> permissive license, or if a better fix might be possible, such
On Mon, Sep 03, 2018 at 09:13:13AM -0500, Eric Blake wrote:
...
> Note that the most recent version of 'install-sh' as installed by Automake
> states:
> # Copyright (C) 1994 X Consortium
looking at my collection of untarred X sources, there's an issue with that:
The comment just before reads some
There has been concern expressed in another (non-public) list that the
AC_PROG_INSTALL macro in autoconf may be causing unnecessary grief to
downstream packagers. This macro requires the existence of an auxiliary
program named 'install-sh' or the older spelling 'install.sh', although
autoconf i
On 11/02/2016 08:06 PM, Raphaël Halimi wrote:
Hi Peter,
Thanks for your answer.
Just to make sure I understand:
CLEANFILES += data/.dirstamp
data/.dirstamp:
@$(MKDIR_P) data
@: > $@
This creates a directory "data", and then a file ".dirstamp" in this
directory by redirecting t
Hi Peter,
Thanks for your answer.
Just to make sure I understand:
> CLEANFILES += data/.dirstamp
>
> data/.dirstamp:
> @$(MKDIR_P) data
> @: > $@
This creates a directory "data", and then a file ".dirstamp" in this
directory by redirecting the (empty) result of the "true" command to
Hi Raphael,
I have the following in my Makefile.am
CLEANFILES += data/.dirstamp
data/.dirstamp:
@$(MKDIR_P) data
@: > $@
data/foo.txt: data/.dirstamp
Cheers,
Peter
On 10/28/2016 05:46 AM, Raphaël Halimi wrote:
Hi,
I have a problem with parallel build trees (a.k.a. VP
utomatically by the build system."
>
>> Unfortunately, it doesn't seem to be true for the SCRIPTS primary (I
>> assume it's true and works as expected for compiled binaries and
>> libraries, I can't know, I'm new to autotools and I'm a sysadmin, I
>>
to be true for the SCRIPTS primary (I
> assume it's true and works as expected for compiled binaries and
> libraries, I can't know, I'm new to autotools and I'm a sysadmin, I
> develop only scripts, nothing compiled).
I've run into this problem before, and just had
Hi,
I have a problem with parallel build trees (a.k.a. VPATH Builds).
I'm trying to use GNU autotools to distribute a shell script that need
to be installed with some other files (sample configuration, man pages,
data, etc etc).
Nothing in this project needs to be compiled, but the scri
On 1.7.2016 16:32, JASON TILLEY wrote:
> I have been editing my Makefile since the original post, so the linker
> is no longer getting ‘-lm -lcsa’. The final lines now look like this:
>
> /bin/sh ./libtool --tag=CC --mode=link /opt/local/bin/gcc -O2 -m64
> -fPIC -g -Wall -L/opt/local/lib -o c
I have been editing my Makefile since the original post, so the linker is no
longer getting ‘-lm -lcsa’. The final lines now look like this:
/bin/sh ./libtool --tag=CC --mode=link /opt/local/bin/gcc -O2 -m64 -fPIC -g
-Wall -L/opt/local/lib -o csabathy src/csabathy-csa.o src/csabathy-svd.o
On 30 June 2016 at 03:03, JASON TILLEY wrote:
> I am trying to create a Makefile.am for a package on github in order to make
> it more friendly to packaging (https://github.com/sakov/csa-c). I am having
> linking problems on my Mac. I’m sure its my complete lack of understanding of
> Automake.
I am trying to create a Makefile.am for a package on github in order to make it
more friendly to packaging (https://github.com/sakov/csa-c). I am having
linking problems on my Mac. I’m sure its my complete lack of understanding of
Automake. My make command executes the following:
depbase=`echo
On Tue, Oct 28, 2014 at 3:34 AM, Wy kevinthesun wrote:
> Finally I tried to test Encoder library as before. I create "Test6" Project
> which only included "Encoder.h" and wrote Makefile.am similarly as Test3:
>
> bin_PROGRAMS = Test6
> Test6_SOURCES = Test6.cpp
>
> Test6_LDFLAGS = -L/home/kevinthe
rkspace/Encoder/src
AM_LDFLAGS = @Test6_LIBS@ @Test6_LDFLAGS@
AM_LDADD = @Test6_LDADD@
CLEANFILES = *~
It gave errors:
DescriptionResourcePathLocationType
make[1]: *** [all-recursive] Error 1Test6 C/C++ Problem
make[2]: *** [Test6] Error 1Test6
Thanks. I missed that at first pass.
Cheers!
On 2014-08-05 20:38, Russ Allbery wrote:
> Johan Persson writes:
>
>> Thanks for the confident boost that its not only me that stumbled upon this
>
>> However, I fail to see how the files that you have added to the "*_FILES"
>> variables act
Johan Persson writes:
> Thanks for the confident boost that its not only me that stumbled upon
> this
> However, I fail to see how the files that you have added to the
> "*_FILES" variables actually get copied to the staging area when
> builddir != srcdir hold (and cleaned up later on) ?
> Woul
ariables at the top (and
> PERL_DIRECTORIES), the clean-local, distclean-local, and check-local
> rules, and all the rules at the bottom of the file. Note that this is
> much more complex than your problem, since it also has to integrate with
> the nati
/?p=kerberos/remctl.git;a=blob;f=Makefile.am;h=50d8f808295fba2f0d9ae3490fe5611f07e3;hb=HEAD
The important bits are the *_FILES variables at the top (and
PERL_DIRECTORIES), the clean-local, distclean-local, and check-local
rules, and all the rules at the bottom of the file. Note that this is
(normal config file handling).
So far so good, and this works perfect when building the in the original
source tree. The problem now comes when doing a staged build.
In addition to these XSL files the manual also uses a number of
additional resources (for example images) which are in the source tree
On 2014-03-20 14:12 +0200, Aurélien Vallée wrote:
[snip exposition]
> libfoo_la_SOURCES = \
> $(top_srcdir)/foo-lib/src/file1.cpp
>
> pkginclude_HEADERS = \
> $(top_srcdir)/foo-lib/include/foo/header1.h \
> $(top_srcdir)/foo-lib/include/foo/subdir/header2.h
[...]
>
Hello,
I have a little problem with Automake to handle the subdirectories when
installing headers.
Here is roughly the project hierarchy that I have:
foo/
foo-bin/
Makefile.am
...
foo-tests/
Makefile.am
...
foo-lib/
Makefile.am
include/
foo/
header1.h
Hello,
I have a little problem with Automake to handle the subdirectories when
installing headers.
Here is roughly the project hierarchy that I have:
foo/
foo-bin/
Makefile.am
...
foo-tests/
Makefile.am
...
foo-lib/
Makefile.am
include/
foo/
header1.h
On Sep 16, 2013, at 11:38 PM, Xochitl Lunde wrote:
>
> On Sep 16, 2013, at 4:52 PM, Nate Bargmann wrote:
>
>>> * On 2013 15 Sep 13:18 -0500, Jules Colding wrote:
>>
So, how do I tell the top-level Makefile.am that it should traverse all
sub-directories building only the libraries,
Jules Colding writes:
> Anyways, thanks for the advises. I'll read the paper on evil
> recursiveness and ponder what to do.
"Non-recursive make" is indeed a nice paradigm for various reasons,
but if you've read earlier threads on this list, actually
_implementing_ it is not quite that trivial.
Y
;Cc: automake@gnu.org
>Subject: Re: Problem with circular dependencies
On Sep 16, 2013, at 4:52 PM, Nate Bargmann wrote:
>> * On 2013 15 Sep 13:18 -0500, Jules Colding wrote:
>
>>> So, how do I tell the top-level Makefile.am that it should traverse all
>>> sub-directo
On Sep 16, 2013, at 4:52 PM, Nate Bargmann wrote:
> * On 2013 15 Sep 13:18 -0500, Jules Colding wrote:
>
>> So, how do I tell the top-level Makefile.am that it should traverse all
>> sub-directories building only the libraries, and then traverse the
>> sub-directories again building only the
* On 2013 15 Sep 13:18 -0500, Jules Colding wrote:
> So, how do I tell the top-level Makefile.am that it should traverse all
> sub-directories building only the libraries, and then traverse the
> sub-directories again building only the test applications?
Would it work to break the test program
On 09/15/2013 11:12 PM, Diego Elio Pettenò wrote:
On Sun, Sep 15, 2013 at 7:16 PM, Jules Colding wrote:
So, how do I tell the top-level Makefile.am that it should traverse all
sub-directories building only the libraries, and then traverse the
sub-directories again building only the test applic
On Sun, Sep 15, 2013 at 7:16 PM, Jules Colding wrote:
>
> So, how do I tell the top-level Makefile.am that it should traverse all
> sub-directories building only the libraries, and then traverse the
> sub-directories again building only the test applications?
>
You don't.
This is one of the reas
libraries. All well there, but the problem
is that they also build test applications which both needs to link to both
libraries.
So, how do I tell the top-level Makefile.am that it should traverse all
sub-directories building only the libraries, and then traverse the
sub-directories again building
On Sun, Sep 1, 2013 at 11:27 PM, Sergey 'Jin' Bostandzhyan wrote:
> Interesting opinion, however, just an opinion and not a fact.
>
An opinion of a distro packager who's been dealing with similar stuff for
years...
> I've been
> using the same "build" approach in MediaTomb and we got packaged
like to package your software.
>
> If I were to find any problem with the build system of your project, I would
> stop looking the moment I find the silly "build" directory, and decide that
> it's not worth packaging at all.
Interesting opinion, however, just an opinion a
at 03:11:11PM -0600, John Calcote wrote:
> > I'm curious as to why it's important to you that build products not land
> in the
> > source tree, especially in light of the fact that you're clearly aware of
> > automake's support for out-of-tree builds. Out-o
inted if I had to switch to a
> setup that is much more inconvenient for me.
>
Because trying to be clever and special with build systems is a bad way to
make a build system. Distributions will dislike you and it's much less
likely that they'd like to package your software.
If I were
-tree builds. Out-of-tree builds exist to solve
> the very problem you're trying so hard to fix.
well, consider the following: your project has several source subdirectories,
some of them with two levels. Even with out of tree builts you end up
having the produced libraries and executables in e
Sergey,
I'm curious as to why it's important to you that build products not land in
the source tree, especially in light of the fact that you're clearly aware
of automake's support for out-of-tree builds. Out-of-tree builds exist to
solve the very problem you're trying
Hi,
OK, never mind, problem solved. It seems that $(top_srcdir) simply did not
expand anymore in _SOURCES. Keeping my structure with the build/Makefile.am
but replacing $(top_srcdir) with '..' did the trick, it works
like a charm now, including in and out of tree builds.
No more wa
Hi,
thanks for your reply, some more questions though:
On Sun, Sep 01, 2013 at 03:08:37PM +0100, Diego Elio Pettenò wrote:
> Is it possible to keep the logic with the in-tree build directory with
> automake 1.14? I did try to move all the logic from build/Makefile.am into
> the top le
On Sat, Aug 31, 2013 at 11:50 PM, Sergey 'Jin' Bostandzhyan <
j...@mediatomb.cc> wrote:
>
> Is it possible to keep the logic with the in-tree build directory with
> automake 1.14? I did try to move all the logic from build/Makefile.am into
> the top level Makefile.am and removing build/Makefile.am
the trick,
however then I can't compile anymore, because .Plo files are not found, i.e.:
toxcore/.deps/libtoxcore_la-DHT.Plo: No such file or directory
Disabling automatic dependency tracking by adding the no-dependencies
solves the problem, but I do not consider this a nice solution.
>From wha
e macro without
the AC_REQUIRE() makes it work for me in both native and cross
compilation cases. Thank you for spotting this!
>>
> Ah, that makes sense. Thanks for the explanation.
>
> So this is neither an autoconf nor an automake problem in the end,
> but an "aut
t; That is because it's coming from this line in AX_SWIG_PYTHON in the
> autoconf-archive.
>
> AC_REQUIRE([AX_PYTHON_DEVEL])
>
Ah, that makes sense. Thanks for the explanation.
So this is neither an autoconf nor an automake problem in the end,
but an "autoconf-arc
On 10/26/12 09:04, Stefano Lattarini wrote:
Hi Václav, sorry for the delay.
On 10/15/2012 09:07 PM, Václav Zeman wrote:
Hi.
I am having a problem with AM_PATH_PYTHON. I have this in my configure.ac:
AS_IF([test "x$with_python" = "xyes"],
Hi Václav, sorry for the delay.
On 10/15/2012 09:07 PM, Václav Zeman wrote:
> Hi.
>
> I am having a problem with AM_PATH_PYTHON. I have this in my configure.ac:
>
>
> AS_IF([test "x$with_python" = "xyes"],
> [AM_PATH_PYTHON([2.3], [:], [:])
>
List the .c and .h files in FOO_SOURCES.
H
obar/george.c and if that works, either put sources next to
>> this Makefile.am or move the guts of it to
>> pathprob/foobar/blah/Makefile.am
>
> Yes, removing the vpath and moving george.c up one level works around
> the problem
> in the test case.
> Should I file a bug
On Mon, Oct 22, 2012 at 5:10 PM, Dan Kegel wrote:
> I don't understand automake's "make dist" support, and could use a clue.
> I've boiled my problem down to the following tiny test case, in which
> "./configure; make" works, but "make dist"
On Mon, Oct 22, 2012 at 3:12 PM, Paul Davis wrote:
>> It doesn't quite solve the problem in my real world situation;
>> "make dist" didn't copy #included files, and I needed to add something like
>> EXTRA_DIST = foobar
>> to pathprob/Makefile.am.
e.am or move the guts of it to
> pathprob/foobar/blah/Makefile.am
Yes, removing the vpath and moving george.c up one level works around
the problem
in the test case.
Should I file a bug for the fact that vpath and dist don't work together,
or is that already documented somewhere?
It do
I don't understand automake's "make dist" support, and could use a clue.
I've boiled my problem down to the following tiny test case, in which
"./configure; make" works, but "make dist" fails. It seems that
make dist is unable to follow vpath. Is th
Hi.
I am having a problem with AM_PATH_PYTHON. I have this in my configure.ac:
AS_IF([test "x$with_python" = "xyes"],
[AM_PATH_PYTHON([2.3], [:], [:])
AX_SWIG_PYTHON
AC_CONFIG_FILES([swig/python/Makefile])])
The problem is that when I am cross compiling it igno
On 03/31/2012 11:20 PM, Bruce Korb wrote:
> On 03/31/12 13:58, Bruce Korb wrote:
>> On 03/31/12 13:44, Bruce Korb wrote:
>>
>> I didn't see it at first because of the comment that made it look like
>> something different from the "installcheck-am" rule.
On 03/31/12 13:58, Bruce Korb wrote:
On 03/31/12 13:44, Bruce Korb wrote:
I didn't see it at first because of the comment that made it look like
something different from the "installcheck-am" rule. The problem
is a *partially* commented out maintainer-clean rule.
installcheck-a
On 03/31/12 13:44, Bruce Korb wrote:
I didn't see it at first because of the comment that made it look like
something different from the "installcheck-am" rule. The problem
is a *partially* commented out maintainer-clean rule.
installcheck-am:
#maintainer-clean: maintainer-
Hey,
I have written a library that use mupdf to render PDF document. mupdf must
be linked statically to that library (there is no mupdf package on any
distro, no shared lib). So I included the mupdf source into my lib tree:
mylib/<--- tree of my lib
mupdf-0.9/ <--- the sub dir containi
edit by hand.,g'
>
> .R:
>
> rm -f $@ .$@.tmp
> $(do_subst) $(srcdir)/$@.R >.$@.tmp
> chmod +x .$@.tmp
> chmod a-w .$@.tmp
> mv -f .$@.tmp $@
>
> .R.pdf:
> ./$*
>
Here I can spot a first problem though: this rule doesn'
Oh, and my Automake Version is 1.10.1.
Am 06.11.2011 um 10:14 schrieb Stefano Lattarini:
> On Saturday 05 November 2011, Stefan wrote:
>> Hi automake list!
>>
>> I'm trying to write a Makefile(.am) to make pdf plots from R scripts.
>> Hence the plot is depending on the script and the data. What
OK, here is my Makefile.am, which at this point works. But it does not include
the data dependency:
@SET_MAKE@
ACLOCAL_AMFLAGS = -I share/misc/m4
SUFFIXES = .R .pdf
noinst_PLOTS = R_Double_new.pdf sample_distris.pdf
noinst_DATA = R_Double_new.histo
noinst_R = R_Double_new.R sample_distris.R
no
On Saturday 05 November 2011, Stefan wrote:
> Hi automake list!
>
> I'm trying to write a Makefile(.am) to make pdf plots from R scripts.
> Hence the plot is depending on the script and the data. What I tried
> is:
>
> SUFFIXES = .R .data .pdf
>
> .R
> make R script executable
>
[Nit: doe
1 - 100 of 624 matches
Mail list logo
