On Tuesday 2024-04-09 05:37, Jacob Bachmeyer wrote:
>
>> In principle it could be posible to output something different to
>> describe this stramge situation explicitly. For instance, output "via
>> stdin" as a comment, or output `stdin/../filename' as the file name.
>> (Programs that optimize
On Friday 2023-12-01 21:13, Mike Frysinger wrote:
>On 17 Jul 2023 16:51, Karl Berry wrote:
>> Hi Jan,
>>
>> Current automake likely won't have anything in store already,
>>
>> Not that I know of.
>>
>> a_SOURCES = $(addprefix aprog/,main.c foo.c bar.c baz.c)
>>
>> I've often wanted
>I didn't explain sufficiently. The submakes I'm talking about are my
>doing, and I want to conditionalize them on whether
>--enable-dependency-tracking is used.
>
>In for example both ntpq/Makefile.am and ntpd/Makefile.am I'm invoking:
>
>(cd ../libntp && make libntp.a)
Yes and if you didn't do
On Saturday 2023-09-30 05:27, Dave Hart wrote:
>I've added code to the ntp.org Makefile.am files to ensure the static
>utility library libntp.a is up-to-date for each program that uses it, to
>ensure the build is correct. When building the project, this adds a bunch
>of extra submake invocations
The regex pattern in function scan_variable_expansions() fails to
report a portability warning when a dollar-escaped dollar sign
precedes the variable:
foo_SOURCES = a.c $$$(patsubst a.c,a,b)
---
lib/Automake/Variable.pm | 5 +++--
t/dollarvar2.sh | 9 +
2 files changed,
The regex pattern in function scan_variable_expansions() fails to
report a portability warning when a dollar-escaped dollar sign
precedes the variable:
foo_SOURCES = a.c $$$(patsubst a.c,a,b)
---
lib/Automake/Variable.pm | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff
On Monday 2023-07-17 06:55, John Darrington wrote:
>Why not just write it as:
>
>a_SOURCES = aprog/main.c \
> aprog/foo.c \
> aprog/bar.c \
> aprog/baz.c ...
You're missing the point.
If you have a hundred, two hundred source files, all the aprog/ prefixes
(and it's rarely *that* short)
Given
a_SOURCES = aprog/main.c aprog/foo.c aprog/bar.c aprog/baz.c ...
The more source files there are to be listed, the longer that line gets,
the bigger the Makefile.am fragment becomes, etc. I am thinking about
how to cut that repetition down. Current automake likely won't have
On Sunday 2023-03-26 14:33, Labeeb Asari wrote:
>
>Basically : compile .c source files with gcc, .cu files with nvcc and
>finally link them together with gcc.
>
>I've tried adding a rule to handle .cu files differently and it does create
>object files for it separately. However while linking,
On Friday 2023-03-03 13:14, ljh wrote:
>Thanks for the hint. I did not know this before.
>
>Found it here, autoconf manual 16.3:
> cd to the directory where you want the object files and executables to
> go and run the configure script. configure automatically checks for
> the source code in
On Friday 2023-03-03 11:13, ljh wrote:
>ifdef is not wrong.
But ifdef is not portable.
On Friday 2023-03-03 10:40, ljh wrote:
>--disable-assert is 1/3 of the way
and cd is the other 2/3.
On Friday 2023-03-03 09:36, ljh wrote:
>Jacob Bachmeyer wrote:
>>$ (mkdir test-build; cd ./test-build && ../src/configure --enable-assert ...)
>>
>>$ (mkdir release-build; cd ./release-build && ../src/configure
>>--disable-assert ...)
On Thursday 2023-03-02 16:12, Jan Engelhardt wrote:
>On Thursday 2023-03-02 09:56, Ilmari Lauhakangas wrote:
>> last year I reported a regression in automake:
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59288
>
>One will find that there is a file m4/xc-am-if
ed in given list of subdirs.
but whatever it does, it causes the 682x duplication you see.
So it's a curl problem. Here's a patch.
>From 74fa25bb5817f38c36c71820731eede6bc3be311 Mon Sep 17 00:00:00 2001
From: Jan Engelhardt
Date: Thu, 2 Mar 2023 16:08:22 +0100
Subject: [PATCH] b
On Wednesday 2023-03-01 19:50, ljh via Discussion list for automake wrote:
>```
>$ make # NDEBUG=1
>$ make NDEBUG=1
>```
>
>Can I have automake.am to define and convey something like this to the output
>Makefile:
>```
>ifdef NDEBUG # if vs. ifdef
>CPPFLAGS += -DNDEBUG
>CFLAGS += -O3 #
On Thursday 2023-02-09 22:53, Dmitry Goncharov wrote:
>
>> If you try this with e.g.
>> OpenBSD make, it will complain.
>
>That's why i asked those questions about portability.
>Do i understand it correctly, that a need to support bmake forces
>automake to abandon a good mechanism to rebuild
On Thursday 2023-02-09 22:33, Dmitry Goncharov wrote:
>
>> .Po file contents control when an .o file -- and thus also
>> the .Po file itself -- is remade.
>> If a .Po file has no practical content, there is no indication
>> that it needs to be remade.
>
>Absence of the depfile is such an
On Wednesday 2023-02-08 03:39, Dmitry Goncharov wrote:
>
>This rule restores a missing depfile file by creating a file with one
>line '# dummy'. (Next version of automake will create an empty one).
>There must have been a reason for generating such a depfile.
depfiles are created ahead of make
On Monday 2022-11-21 16:22, Thomas Jahns wrote:
>The question consequently is: how would I create a Makefile.am that accounts
>for a list of C sources, when the sources are not yet present/known from the
>perspective of automake?
I don't see that working even without automake. Once make has
(With automake 1.16.5), your typical Makefile.am produces a Makefile
like so:
-8<- Makefile
AMTAR = $${TAR-tar}
am__tar = $${TAR-tar} chof - "$$tardir"
am__untar = $${TAR-tar} xf -
dist-gzip: distdir
tardir=$(distdir) && $(am__tar) | eval GZIP= gzip $(GZIP_ENV) -c
>$(distdir).tar.gz
On Saturday 2022-11-19 09:11, madmurphy wrote:
>I guess it does make sense. But then what might be missing to Automake are
>libXXX_la_AM_CFLAGS, libXXX_la_AM_CPPFLAGS and libXXX_la_AM_LDFLAGS
>variables, in which the global AM_CFLAGS, AM_CPPFLAGS and AM_LDFLAGS are
>automatically pasted (whereas
On Friday 2022-11-18 22:57, Russ Allbery wrote:
>madmurphy writes:
>
>> However, if at the same time I set also the libfoo_la_CPPFLAGS variable (no
>> matter the content), as in the following example,
>
>> AM_CPPFLAGS = \
>> "-DLIBFOO_BUILD_MESSAGE=\"correctly defined via AM_CPPFLAGS\""
On Wednesday 2022-10-05 23:24, Karl Berry wrote:
>
>What troubles me most is that there's no obvious way to debug any test
>failure involving parallelism, since they go away with serial execution.
>Any ideas about how to determine what is going wrong in the parallel
>make? Any way to make
On Wednesday 2022-10-05 00:58, Karl Berry wrote:
>
>Nothing has changed in the tests. Nothing has changed in the automake
>infrastructure. Everything worked for me a few weeks ago. Furthermore,
>Jim ran make check with much more parallelism than my machine can
>muster, and everything succeeded
On Wednesday 2022-08-31 23:20, Karl Berry wrote:
>
>Should the rpmlint check be adjusted to cater to the GNU FHS?
>
>[..]
>Also, GNU (as an organization) never had anything to do with the FHS,
I just called it GNU FHS to distinguish it from the LF/LSB FHS. Autotools
for example defaults to
Greetings.
A check was impleneted in rpmlint[1] that verifies that a manual page file such
as "foo.3" has indeed been placed in ${mandir}/man3, and not, say,
${mandir}/man4.
[1]
https://github.com/rpm-software-management/rpmlint/commit/6fe4be934d60119f9a969a8b8198037e3f1c7941
Ironically, that
On Monday 2022-05-02 22:52, Karl Berry wrote:
>- @echo '# dummy' >$@-t && $(am__mv) $@-t $@
>+ @: >>$@
>
>2) without the mv I fear we are no longer noticing write failure. -k
I see no reason why mv would be so crucial.
Case 1. Lack of permission. The ">" operation is the one that
On Monday 2022-05-02 15:31, Jan Engelhardt wrote:
>> If empty files are ok (assuming they are needed at all), can they be produced
>> with a minimum number of executions of a 'touch' command?
>
>Better yet, they can be produced with the ">>" shell builtin, sk
On Monday 2022-05-02 15:18, Bob Friesenhahn wrote:
> On Mon, 2 May 2022, Jan Engelhardt wrote:
>>
>> Indeed, if a source code package consists of 1 files, then configure
>> produces another 10k files for the stuff in the ".deps" directories.
>> There is n
On Monday 2022-05-02 14:20, Thomas Jahns wrote:
Is there a way to speed 'automake' up?
>>>
>>> [...let] ephemeral builds [..] use /dev/shm [...]
>>
>> There ought to be little difference [...] automake, that's nowhere near as
>> IO-heavy as untarring kernel source archives. It's much more
On Friday 2022-04-29 22:59, Thomas Jahns wrote:
> On 4/27/22 3:49 PM, R. Diez wrote:
>> Is there a way to speed 'automake' up?
>
> While you are probably looking for system-independent advice, the best results
> I've had with speeding up ephemeral builds is to simply use /dev/shm for
> backing
On Sunday 2022-03-27 23:22, Karl Berry wrote:
>It seems the basic inconsistency is whether CPPFLAGS is considered a
>"user variable" or not. In earlier eras, it wasn't [...]
In earlier eras of what exactly?
As for make, it never made a distinction between user variables or otherwise,
at least
On Tuesday 2022-02-15 07:16, Daniel Herring wrote:
>
> Maybe a next-generation configuration tool should start by defining interfaces
> for user interactions and build tools. This would allow CLI and easy GUI and
> IDE users, integration with multiple build systems, static and dynamic
>
On Tuesday 2021-09-21 22:32, Karl Berry wrote:
>Thanks much. I was thinking I should avoid that since the .[ly] are not
>ultimate sources, but if it works, fine with me.
>
>jan>
>BUILT_SOURCES = foo.y
>foo.y: foo.cweb
>somecommands
>
>That would be sensible, but I failed
On Tuesday 2021-09-21 19:02, Karl Berry wrote:
>Suppose I want to generate a lex or yacc input file from another file,
>e.g., a CWEB literate program. Is there a way to tell Automake about
>this so that the ultimately-generated parser/lexer [.ch] files are saved
>in srcdir, as happens when [.ly]
On Sunday 2021-08-29 22:44, Karl Berry wrote:
>Subject: [PATCH v2] automake: add install dep on install-libLTLIBRARIES to
> all
> targets
>
>Thanks. Have you run make check? (In practice, make -j12 check or similar.)
>Always good to make sure nothing old breaks ... -k
# TOTAL:
-libLTLIBRARIES
therefore potentially breaking `make install -j`. Rectify this by
depending on install-libLTLIBRARIES not just for bin_PROGRAMS, but
all PROGRAMS and LTLIBRARIES.
Signed-off-by: Jan Engelhardt
---
Also available from https://github.com/jengelh/automake
if that is easier to download
-libLTLIBRARIES
therefore potentially breaking `make install -j`. Rectify this by
depending on install-libLTLIBRARIES not just for bin_PROGRAMS, but
all PROGRAMS and LTLIBRARIES.
Signed-off-by: Jan Engelhardt
---
bin/automake.in | 23 +--
1 file changed, 17 insertions(+), 6
Greetings.
Consider a Makefile.am like so:
bin_PROGRAMS = aprogram
sbin_PROGRAMS = otherprogram
lib_LTLIBRARIES = library1.la
pkglib_LTLIBRARIES = library2.la
library2_la_LIBADD = library1.la
this will produce, under automake 1.15/1.16, a Makefile.in
Using automake-1.13.4, when using the following Makefile.am fragment,
---8---
bin_PROGRAMS = foo
foo_SOURCES = foo.c bar.k
.k.${OBJEXT}:
gcc -x c -c $ -o $@
---8---
I observe that bar.o is not built and not linked into foo.
---8---
make V=0
CC foo.o
CCLD foo
On Wednesday 2014-11-12 20:15, Nick Bowler wrote:
On 2014-11-12 16:58 +0100, Jan Engelhardt wrote:
Using automake-1.13.4, when using the following Makefile.am fragment,
.k.${OBJEXT}:
gcc -x c -c $ -o $@
I observe that bar.o is not built and not linked into foo.
Indeed, the use
With automake-1.13.4 automake-1.14, when there is a _SOURCES =
../blah.c, make does not properly run because .deps is gone too early.
File set:
# Makefile.am
SUBDIRS = b
noinst_PROGRAMS = foo
# configure.ac
AC_INIT([a],[0])
AM_INIT_AUTOMAKE([foreign subdir-objects])
AC_PROG_CC
Given a Makefile.am with
myprog_LDADD = -pthread
automake will correctly output this warning
Makefile.am:17: error: linker flags such as '-pthread'
belong in 'myprog_LDFLAGS'
It would be nice to also have automake report -l flags in LDFLAGS that
actually belong into
The
help2man: can't get `--help' info from ./aclocal
error seems to have reappeared in automake-1.13.1 (judging from
http://gnu-automake.7480.n7.nabble.com/Man-pages-for-automake-and-aclocal-td11966.html)
help2man is of version 1.40.12.
---
Executing(%build): /bin/sh -e
On Wednesday 2013-01-09 19:11, Stefano Lattarini wrote:
On 01/09/2013 05:05 PM, Jan Engelhardt wrote:
The
help2man: can't get `--help' info from ./aclocal
error seems to have reappeared in automake-1.13.1 (judging from
http://gnu-automake.7480.n7.nabble.com/Man-pages-for-automake
On Wednesday 2013-01-09 22:27, Stefano Lattarini wrote:
Now I just have to figure out why someone thought that openSUSE
should create the manpages directly...
Good question
What happens if you do this instead?
help2man -S FSF ./t/wrap/aclocal-1.13 output.1
Does this fix your problem?
Hi,
Is there an option to yield an error instead of a warning
if Makefile.in needs to be regenerated, but can't?
The case before me is that iptables's Makefile.am in openSUSE is
patched after tarball extraction. But, due to 1. $PEBKAC not calling
autoreconf, 2. the system having automake-1.12
Much to my disappointment, I found that the newly-released libkmod v5
has made the following non-trivial change to its source tree, the latter
of which I want to bring to attention:
commit e479598b7d19ae7be45bf5329d6e4df32d646c16
diff --git a/Makefile.am b/Makefile.am
On Sunday 2012-01-01 10:24, Stefano Lattarini wrote:
On 12/31/2011 12:29 AM, Jan Engelhardt wrote:
I have seen user-induced lines in Makefile.am like these in a handful
of packages:
Which packages? I need more information if I am to attempt an informed
guess ...
${pkgconfig_DATA
I have seen user-induced lines in Makefile.am like these in a handful
of packages:
${pkgconfig_DATA}: ${top_builddir}/config.status
Given that automake 1.11.1/autoconf 2.68 seem to automatically recreate
files specified in AC_CONFIG_FILES when configure.ac is changed, what is
the
Hi,
While trying to utilize Autotools in a preexisting project that
previously just relied on Makefiles, I came across ylwrap failing for
some absurd, unknown reason. I couldn't help but run sh -x and debug it
piecewise.
So what's ultimately done is running flex inside a temp directory,
On Sunday 2010-10-31 16:42, Philip Herron wrote:
While trying to utilize Autotools in a preexisting project that
previously just relied on Makefiles, I came across ylwrap failing for
some absurd, unknown reason. I couldn't help but run sh -x and debug it
piecewise.
So what's ultimately
[Note that this has nothing to do with the bootstrap file]
On Sunday 2009-11-15 17:44, Alfred M. Szmidt wrote:
Index: automake/m4/init.m4
===
--- automake.orig/m4/init.m4
+++ automake/m4/init.m4
@@ -107,6 +107,7 @@
On Saturday 2009-11-14 14:06, Ralf Wildenhues wrote:
Hi Jan,
* Jan Engelhardt wrote on Mon, Nov 09, 2009 at 02:09:14AM CET:
in the automake tarballs, the 'bootstrap' script is missing, but it
would be needed when modifying any of the automake files in a tarball.
Sounds reasonable to me
Hi,
in the automake tarballs, the 'bootstrap' script is missing, but it
would be needed when modifying any of the automake files in a tarball.
In other words, when used in an rpm build script:
Source: automake-1.11.tar.bz2
Patch1: foobar.diff modifying m4/init.m4
Not running bootstrap after
Hi,
when one decides to drive make in a non-recursive fashion, one has to
write an Automake file like this:
lib_LTLIBRARIES = foo/bar.la
foo_bar_la_SOURCES = foo/one.c foo/two.c
Usually I stuff that into a file called foo/Automakefile and include
foo/Automakefile from the real Makefile.am.
On Sunday 2009-05-24 15:24, Thomas Dickey wrote:
On Sun, 24 May 2009, Bruno Haible wrote:
- The `silent-rules' option enables Linux kernel-style silent build output.
This option requires the widely supported but non-POSIX `make' feature
of recursive variable expansion,
We are talking
On Sunday 2009-05-24 16:25, Andreas Schwab wrote:
Bruno Haible br...@clisp.org writes:
- The -m64 flag is the default on bi-arch Linux systems.
This is wrong.
- The -m32 flag has to be passed as part of both CC / CXX and LDFLAGS.
That should not be necessaray, since any command that
On Sunday 2009-05-24 19:35, Bob Friesenhahn wrote:
On Sun, 24 May 2009, Andreas Otto wrote:
I want to create an language binding for a C libraray
this mean I have as input an file called csmsgque.cs
and get as output an csmsgque.dll on unix
It seems like what is needed is C#
On Friday 2009-05-08 06:23, Adam Mercer wrote:
I have noticed some strange behaviour with the build system on a
project I am working on, consider the following:
$ ./configure --prefix=/path/1
$ make
$ make install
$ ./configure --prefix=/path/2
$ make
$ make install
I would expect the make
On Monday 2009-05-04 08:06, John Calcote wrote:
On 5/3/2009 3:32 PM, Gerald I. Evenden wrote:
In a shared library there are about 8 routines out over 100 that refer to
libgsl and libpthread. A frequent situation may arise where an application
program has no need for using the 8 procedures
On Sunday 2009-05-03 17:41, Gerald I. Evenden wrote:
libproject_la_LDFLAGS = -version-info 2:0:1
which worked fine when with previous loading of a library with 2:0:0
versioning code.
But now, when I go through the autoreconf, configure, compile and install I
get:
libproject.so.1.1.0
Which
On Sunday 2009-05-03 18:58, John Calcote wrote:
It appears that Libtool is smart enough to detect ridiculous cases, but it
should probably throw an error of some sort, rather than simply generate
code with a different version number.
Since libtool is just a linker as far as is considered here,
On Sunday 2009-05-03 20:40, Gerald I. Evenden wrote:
What I did to the library was add several procedures
That in itself would cause a bump in the 'current' number to 3.
but the original
functions were not changed nor affected.
So 'age' becomes 1, since you are still supporting (3-1) = 2.
On Sunday 2009-05-03 23:32, Gerald I. Evenden wrote:
In a shared library there are about 8 routines out over 100 that refer to
libgsl and libpthread. A frequent situation may arise where an application
program has no need for using the 8 procedures infected with other library
needs.
At the
On Friday 2009-05-01 09:57, Ralf Wildenhues wrote:
Hi Jan,
* Jan Engelhardt wrote on Thu, Apr 30, 2009 at 09:05:07PM CEST:
Output seems crushed, so restore the original behavior.
Can you explain this, please?
The original submission I did around October 2008 followed the
Linux-style output
Output seems crushed, so restore the original behavior.
---
automake.in |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: automake/automake.in
===
--- automake.orig/automake.in
+++ automake/automake.in
@@ -1199,7
On Monday 2009-04-27 22:27, Ralf Wildenhues wrote:
CXXbar.o
CXXLD prog
$ grep CXX_0 Makefile.in
am__v_CXX_0 = @echo CXX$@;
Thanks for the bug report. Fixed with the patch below.
I also had a look at the automake source, and I rather find
this the problem (in
On Tuesday 2009-03-31 01:21, Ralf Wildenhues wrote:
I'm pleased to announce the Automake 1.10b test release. It contains
a bunch of new features, and a bunch of bugfixes over previous versions,
and probably a bunch of new bugs. Highlights, in no particular order:
I just now tried
On Saturday 2009-04-25 23:19, Jan Engelhardt wrote:
On Tuesday 2009-03-31 01:21, Ralf Wildenhues wrote:
I'm pleased to announce the Automake 1.10b test release. It contains
a bunch of new features, and a bunch of bugfixes over previous versions,
and probably a bunch of new bugs. Highlights
On Tuesday 2009-03-31 01:21, Ralf Wildenhues wrote:
I'm pleased to announce the Automake 1.10b test release. It contains
a bunch of new features, and a bunch of bugfixes over previous versions,
and probably a bunch of new bugs. Highlights, in no particular order:
[...]
As silent-rules stand
On Thursday 2009-04-23 04:54, automake wrote:
Hi
I have a similar problem with giving a customized target. I have included
target into Makefile.am
as
extra:
...nm
...link
But the default target for makefiles from configure.ac is all. Is there a
way to add this target to all
On Thursday 2009-04-23 14:51, Bob Rossi wrote:
What's the advantage over just installing binaries into $(bindir)
without stripping them? **Non-brain-damaged** systems won't
load them from the file anyway for normal execution.
[emphasis added by me]
On mingw/msys the executables with debug
On Wednesday 2009-04-22 07:33, Ralf Wildenhues wrote:
* JRS wrote on Wed, Apr 22, 2009 at 07:02:55AM CEST:
I was setting up build infrastructure once again when it occurred to
me, hmm, wouldn't it be nice if automake had default targets for
installing symbols?
For example, make install-syms
On Saturday 2009-04-18 19:21, Monty Taylor wrote:
Solaris on Sparc supports both 32 and 64 bit binaries, with builds
defaulting to 32-bit. (Thanks backwards compatibility for proprietary
software!)
On SPARC, choosing 32-bit is an architectural decision rather
than a software or political one.
On Saturday 2009-04-18 22:06, Russ Allbery wrote:
Russ Allbery r...@stanford.edu writes:
Ralf Wildenhues ralf.wildenh...@gmx.de writes:
[1] I'm asking because Automake 1.11 will reliably not install files if
their respective installation directory is empty. This is not yet
functional in
On Saturday 2009-04-18 22:45, John Calcote wrote:
Oh, you mean if the value of the *variable* is empty (following the
thread), not the directory itself. D'oh, sorry, that should have been
obvious to me from context. Never mind. :)
No, I also thought of empty directories. Quote from
On Tuesday 2009-04-14 08:09, Ralf Wildenhues wrote:
Here's why:
[...]
Yet another way out: remove per-Makefile.am `AUTOMAKE_OPTIONS =
silent-rules' as well as `automake --silent-rules' so that the only way
to specify them is as option listed in AM_INIT_AUTOMAKE. This may be
inconvenient for
Hi,
I am currently using automake in a Windows-related project; there is a
(pure) mingw compiler in c:\mingw, and cygwin is installed in c:\cygwin.
Now I noticed that Makefile.in, as generated by automake, has a
CYGPATH_W variable which is `echo` on Unices, and `cygpath -w` on
Cygwin. The
On Friday 2009-04-10 22:19, Jan Engelhardt wrote:
AM_CFLAGS = -I${abs_top_builddir}/subproject
AM_LDFLAGS = -L${abs_top_builddir}/subproject
This gets expanded into -I/home/User/project/subproject, but the mingw
compiler of course tries to search in C:\home\user\project\subproject
instead of c
On Thursday 2009-04-02 23:45, Gerald I. Evenden wrote:
After trying so many options related to libraries I am exhausted.
I have a simple program that needs to link with a shared library installed
in /usr/local/lib.
When using my own simple Makefile and simply adding -lproject -lm everything
On Sunday 2009-03-22 12:23, Ralf Wildenhues wrote:
Hello everyone,
just to let you know, after 1.11 I intend to change the branch setup a
bit. When branch-1-11 is created, I will also create a branch maint,
which will then receive bug fixes appropriate for both 1.11.x and 1.11a.
The maint
Hi Ralf,
On Tuesday 2009-03-24 22:48, Ralf Wildenhues wrote:
And: once branch-1.11 development finally ceases, it can be deleted.
This works because the commits remain reachable via the release tags.
If necessary, the branch pointer can simply be recreated.
What would be the advantage of
Hi,
when a scanner.l file contains
%option prefix=foo_
flex will output to lex.foo_.c instead of lex.yy.c,
causing ylwrap to fail
(automake runs:)
/bin/sh ../ylwrap scanner.l lex.yy.c scanner.c -- flex
How would one best proceed here? Especially when there are
Hi,
when one uses --header-file in conjunction with ylwrap, the header file
is produced in the temporary directory ylwrap runs in instead of
${srcdir}. I think this should be addresses somehow - I'm open
to suggestions or ideas on how this could be tackled. One way would
probably just to add
On Wednesday 2009-03-11 21:06, Ralf Wildenhues wrote:
* Ralf Wildenhues wrote on Sun, Mar 08, 2009 at 10:46:40AM CET:
The current patch still has a couple of warts in that --silent-rules
should turn off portability-recursive warnings independently of the
command line argument order. This is
On Wednesday 2009-03-11 22:43, Ralf Wildenhues wrote:
* Jan Engelhardt wrote on Wed, Mar 11, 2009 at 09:34:20PM CET:
On Wednesday 2009-03-11 21:06, Ralf Wildenhues wrote:
Do we want to allow a command line knob (--silent-rules) to turn
off `silent' mode, or do we force developers to either
On Monday 2009-03-09 15:57, Ralf Corsepius wrote:
For this patch, I'm unsure if we should even add it at all.
FWIW: I am opposed to it.
All this silencing stuff does is to add further potential sources of errors.
Which ones, please?
Those yet to be discovered.
Oh what great
On Monday 2009-03-09 16:10, Ralf Corsepius wrote:
For this patch, I'm unsure if we should even add it at all.
FWIW: I am opposed to it.
All this silencing stuff does is to add further potential sources of
errors.
Which ones, please?
Those yet to be discovered.
Oh what
On Monday 2009-03-09 16:54, Ralf Corsepius wrote:
which has some similar silent mode too (by default even!)...
Correct. that's one of cmake's sillynesses. It hides away the silent bugs a
package suffers from.
Potential bugs in the command line invoking $CC that automake generates
just go
On Monday 2009-03-09 14:45, almkglor wrote:
What I'd like to know is, does using Automake+Autoconf require me to license
distributions built using them with the GPL?
[...]
While GPL is OK by me, it might not be as popular among other developers. ^^
I could list apache-httpd2 as an example
On Sunday 2009-03-08 10:01, Ralf Wildenhues wrote:
Another minor issue I don't quite like yet: before this change,
the code was quite carefully laid out to be performant in the
generic fastdep case: GNU make can avoid spawning a shell for
a command, when the command line to be executed can
On Saturday 2009-03-07 16:16, Ralf Wildenhues wrote:
Hello Jan, all,
I've worked a bit on the less verbose automake stuff, and put the result
up as a branch in the git repository:
git clone git://git.savannah.gnu.org/automake.git
git branch je-silent origin/je-silent-am
On Saturday 2009-02-28 11:16, Ralf Wildenhues wrote:
Modern Automake does support appending. But only appending to a
variable that has already been set.
Yes. This is done primarily to be able to diagnose typos, e.g.,
foolish =
foo1ish += bar
[...]
Is it worth the hassle? It's certainly
On Thursday 2009-02-26 00:44, Allan Caffee wrote:
What is the cleanest to way to append something to a builtin variable
(e.g. MAINTAINERCLEANFILES) from an Automake header.[...]
Is there a cleaner, ideally non-invasive method for
adding things to these builtin lists?
In one project I use --
On Wednesday 2009-02-04 10:33, Michel Briand wrote:
Furthermore I noted that .o files are twice for one source file:
$ find . -name main.* -ls
49646234 -rw-r--r-- 1 michel users 266 fév 4 10:22 ./main.lo
44401878 -rw-r--r-- 1 michel users5268 fév 4 10:22
On Monday 2009-01-26 23:33, Adam Nielsen wrote:
$ g++ -fPIC -c -o main.o main.cpp -I/usr/include/boost-1_37/ g++ -o
test.so main.o -shared
This works since main.cpp is being compiled to main.o with PIC. However,
Boost
is not involved here so it proves nothing about Boost.
It does prove
On Sunday 2009-01-25 05:46, Adam Nielsen wrote:
x86_64-pc-linux-gnu/bin/ld:
.../lib64/libboost_system-mt-1_37.a(error_code.o): relocation R_X86_64_32S
against `a local symbol' can not be used when making a shared object;
recompile with -fPIC
.../lib64/libboost_system-mt-1_37.a: could not
On Monday 2009-01-26 01:23, Adam Nielsen wrote:
x86_64-pc-linux-gnu/bin/ld:
.../lib64/libboost_system-mt-1_37.a(error_code.o): relocation R_X86_64_32S
against `a local symbol' can not be used when making a shared object;
recompile with -fPIC
.../lib64/libboost_system-mt-1_37.a: could not
1 - 100 of 148 matches
Mail list logo
