On Sunday 2009-01-25 18:42, Andreas wrote:
>
>When you specify a list of files for a rule you put every file in a line like
>this.
>
>fileA.c \
>fileB.c \
>fileC.c
>
>now if 2 independent people add another file fileD and fileE to that list you
>have a conflict because both of them m
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_syste
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
On Tuesday 2009-01-20 10:37, Lorenzo Bettini wrote:
> Hi
>
> I'd need to use the function
>
> g_find_program_in_path ()
>
> in glib, if glib is found in the system...
>
> which is the best way of doing that? using the pkconfig or some specific
> macro
> provided by glib itself?
Yes,
PKG_CONFI
On Friday 2009-01-02 20:57, Matěj Týč wrote:
>> Did you try regenerating the aclocal files?- usually done by `autoreconf
>> -fi`.
>
>Yes, I tried it and it did not help, I still get the error. Are there
>any files where the macro is supposed to be defined to check?
>
Grepping in the automake tre
On Friday 2009-01-02 20:26, Matěj Týč wrote:
>> I could not find it in the manual either, so the macro is probably
>> not the right one to start with.
>
>It is in the manual, of course (that's where I have found it). Look
>here:
>http://sources.redhat.com/automake/automake.html#Conditionals
Ah o
Hi,
I reckon that %-style suffix rules (e.g. "%.o: %.c") are rather
unportable, but I wonder how the old-fashioned suffix rule for
%.1: %.1.php
would look like.
Hi,
given a configure.ac which defines AM_INIT_AUTOMAKE([-Wall]),
running `automake -Wnone` still produces the warnings I had with -Wall.
I think command line should override any earlier flags.
On Friday 2009-01-02 17:33, Matěj Týč wrote:
>Hello,
>I would like to use the AM_COND_IF macro in my configure.ac, but when I
>run autoreconf, I get an error message saying that the macro couldn't be
>found anywhere.
I could not find it in the manual either, so the macro is probably
not the righ
On Monday 2008-12-22 21:36, Ralf Wildenhues wrote:
>> >On Monday 2008-12-15 21:19, William Pursell wrote:
>>
>> >The make info pages mention that $? expands to “all the prerequisites
>> >that are newer than the target”, and that sounds like there could be
>> >more than just the .c file.
>> >
>> >I
On Monday 2008-12-15 21:48, Jan Engelhardt wrote:
>On Monday 2008-12-15 21:19, William Pursell wrote:
>>
>>Thanks for this Jan, it is really nice functionality. I don't
>>know if this is a portability issue, but I think it would be nice
>>to
On Monday 2008-12-15 21:19, William Pursell wrote:
>
>Thanks for this Jan, it is really nice functionality. I don't
>know if this is a portability issue, but I think it would be nice
>to change $< to $? in this section:
>
>> +'am__1verbose_CCLD_1 = @echo " CCLD" $@ "<-" $<;',
>
On Monday 2008-12-15 08:32, William Pursell wrote:
>Jan Engelhardt wrote:
>
>> third round here of the automake-tranquility patch from me.
>> Updates from previous attempts:
>
>I've been looking through the archive and haven't
>noticed any followup on
On Thursday 2008-12-11 21:38, Monty Taylor wrote:
>Hey all,
>
>I'm wondering if there is a best practice for getting paths such as
>locaeldir or datadir into source code. As it stands now in the Makefile
>I've got:
>
>prefix= /usr/local
>datarootdir= ${prefix}/share
>localedir = ${datarootdir}/lo
On Wednesday 2008-12-10 16:04, Bob Friesenhahn wrote:
> On Wed, 10 Dec 2008, Tom Browder wrote:
>>> * Tom Browder wrote on Wed, Dec 10, 2008 at 01:38:53AM CET:
>>> > Is it "legal" to use the "+=" operator in lieu of "\" when listing
>>> > members of a variable in Makefile.am's?
>>>
>>> Yes. In t
On Tuesday 2008-12-09 19:50, Ralf Wildenhues wrote:
>> >Just using
>> > ./configure CFLAGS=-fPIE
>> >
>> >should work fine, or put it in target_CFLAGS if you only want some
>> >targets to be PIE. Be sure to use recent Libtool, so that libraries
> ^^^
Hi Ralf,
On Tuesday 2008-12-09 07:15, Ralf Wildenhues wrote:
>* Jan Engelhardt wrote on Tue, Dec 09, 2008 at 12:11:52AM CET:
>>
>> is there a chance automake and/or libtool would support -fPIE for
>> executables, much like libtool unconditionally turns on -fPIC for shared
Hi,
is there a chance automake and/or libtool would support -fPIE for
executables, much like libtool unconditionally turns on -fPIC for shared
libraries?
Hi,
at the moment, the pam_mount project uses the following hack to
workaround a libtool warning message:
# Makefile.am (abridged)
bin_PROGRAMS = mount.crypt
mount_crypt_SOURCES = nlt-loop.c ...
lib_LTLIBRARYES = pam_mount.la
pam_mount_la_SO
On Wednesday 2008-11-05 09:38, Jan Engelhardt wrote:
>
>third round here of the automake-tranquility patch from me.
>Updates from previous attempts:
>1. using am__ prefix
>2. removed the strange find_link_verbose() function
>3. verbosity selectable in configure.ac too
>
On Sunday 2008-11-30 18:07, NightStrike wrote:
>>>
Is the following kosher?
>>>
>>>It will produce two 32-bit libraries on all architectures where
>>>gcc defaults to a 32-bit output.
>>
>> (In other words, you are missing -m64. And perhaps some logic
>> so that lib64 is not built in pure 32-bi
On Sunday 2008-11-30 02:24, Jan Engelhardt wrote:
>On Sunday 2008-11-30 01:52, NightStrike wrote:
>
>>Is the following kosher?
>
>It will produce two 32-bit libraries on all architectures where
>gcc defaults to a 32-bit output.
(In other words, you are missing -m64. And
On Sunday 2008-11-30 01:52, NightStrike wrote:
>Is the following kosher?
It will produce two 32-bit libraries on all architectures where
gcc defaults to a 32-bit output.
>shell32src=libsrc/shell32.c
>
>lib32_LIBRARIES += lib32/libshell32.a
>lib32_libshell32_a_SOURCES = $shell32src
>lib32_libshe
On Saturday 2008-11-29 17:30, Ralf Wildenhues wrote:
>> On Friday 2008-11-28 21:37, Bob Friesenhahn wrote:
>> >
>> > It makes sense to me that periodically Automake maintainers make an
>> > evaluation (and with the blessing of the FSF) intentionally
>> > deprecate generation of certain archive typ
On Saturday 2008-11-29 17:04, Bob Friesenhahn wrote:
> On Sat, 29 Nov 2008, Jim Meyering wrote:
>>
>> I have been following lzma-utils development closely for some time,
>> and my impression is that xz obviates lzip. I would not want to
>> encourage use of lzip without a convincing argument to th
On Saturday 2008-11-29 10:06, Jim Meyering wrote:
>Jan Engelhardt <[EMAIL PROTECTED]> wrote:
>> On Friday 2008-11-28 17:21, Bob Friesenhahn wrote:
>>> Since LZIP support has appeared apparently out of the blue (no
>>> prior discussion on this list), and Automake
On Friday 2008-11-28 21:37, Bob Friesenhahn wrote:
>
>> > If an archive format was ever offered before, the feeling is that
>> > it must continue to be offered for the rest of time.
>>
>> *sigh* well, everybody is entitled to do his own liking and
>> if that's providing all formats just because.
>
On Friday 2008-11-28 20:37, Ralf Wildenhues wrote:
>> When you graph git://dev.medozas.de/pam_mount with `gitk --all` for example,
>> you may find that practice between 0.40--0.43 or 0.45--0.47.
>
>[...] Another thing that bothers me when merging from stable to
>master is that I'm not used to deve
On Friday 2008-11-28 20:05, Ralf Wildenhues wrote:
>> 14:04 yaguchi:../test/obj > make distcheck V=2
>> [...]
>> make[1]: Entering directory `/dev/shm/test/obj/foo-0/_build'
>> depbase=`echo foo.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
>> gcc -DPACKAGE_NAME=\"foo\" -DPACKAGE_TARNAME=\"foo\"
On Friday 2008-11-28 19:38, Bob Friesenhahn wrote:
> On Fri, 28 Nov 2008, Jan Engelhardt wrote:
>
> It was my impression that Automake adopted LZMA utils without fully
> evaluating the impact. My own package is now distributing .lzma
> packages.
It's only great until somet
On Friday 2008-11-28 17:21, Bob Friesenhahn wrote:
> Since LZIP support has appeared apparently out of the blue (no
> prior discussion on this list), and Automake already had LZMA
> support, can someone please explain LZIP vs LZMA and why we now
> have at least two LZMA compressed targets?
See h
commit 6f949a61df1cfc778ab91de037b611bd8bad3735
Author: Jan Engelhardt <[EMAIL PROTECTED]>
Date: Thu Nov 27 23:28:35 2008 +0100
Add LZIP support
---
ChangeLog | 10 ++
Makefile.in |8 +++-
automake.in |3 ++-
doc/automak
Hi Ralf,
On Friday 2008-11-28 06:25, Ralf Wildenhues wrote:
>* Jan Engelhardt wrote on Thu, Nov 27, 2008 at 11:12:24PM CET:
>>
>> ---<8--- Makefile.am
>> AUTOMAKE_OPTIONS = foreign subdir-objects
>> noinst_DATA = foo.txt
>
>> make distcheck
>
>&
Hi,
here's a problem I just cannot figure out on my own -- distcheck always
fails on data using the following test files:
---<8--- Makefile.am
AUTOMAKE_OPTIONS = foreign subdir-objects
noinst_DATA = foo.txt
--->8---
---<8--- configure.ac
AC_INIT([foo], [0])
AM_INIT_AUTOMAKE([-Wall])
AC_CONFIG
Hi,
the automake info page has this to say about distcleancheck:
> If you want `distcleancheck' to ignore built files that have not
>been cleaned because they are also part of the distribution, add the
>following definition instead:
>
> distcleancheck_listfiles = \
> find -type f -e
On Monday 2008-11-10 20:53, Bob Friesenhahn wrote:
> On Mon, 10 Nov 2008, Jan Engelhardt wrote:
>
>> for shared libraries, it is possible to use
>> myshared_so_LDFLAGS = -module
>> to tell automake not to warn about the missing "lib" prefix.
>> For
Hi,
for shared libraries, it is possible to use
myshared_so_LDFLAGS = -module
to tell automake not to warn about the missing "lib" prefix.
For static libraries however, something like that does not
work since there is no ld involved, and automake warns
about the missing lib prefix. Is the
and at runtime through `make V=level`
Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>
---
automake.in | 134
lib/am/depend2.am | 21
lib/am/lex.am |3 -
lib/am/library.am |4 -
lib/am/ltlibrary.
On Friday 2008-10-24 03:19, Jan Engelhardt wrote:
>On Thursday 2008-10-23 19:20, Ralf Wildenhues wrote:
[...]
I noticed that AM_VERBOSE_YACC is not used when in the .l.c and
.y.c rules. Do you know why?
>>> ## In fast-dep mode, we can always use -o.
>>> ## For non-
On Monday 2008-10-27 08:19, Neel Basu wrote:
>On Sunday 26 Oct 2008 11:41:26 pm Ralf Wildenhues wrote:
>
>> $(top_builddir)/cgi++/libcgixx.la:
>> cd $(top_builddir)/cgi++ && $(MAKE) $(AM_MAKEFLAGS) libcgixx.la
>>
>> in the Makefile.am files that need it. If the cgi++ directory has
>> BU
On Thursday 2008-10-23 19:20, Ralf Wildenhues wrote:
>
>Anyway, when we use nonconforming constructs then it's probably safer if
>they are default-off, so the developer can choose to enable it and knows
>the limitation. I suppose we can have an Automake option 'silent' or so
>(better name suggest
le.am.
Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>
# All rights are handed to the automake team.
---
automake.in | 91 ++--
lib/am/depend2.am |6 +++
lib/am/library.am |5 +-
lib/am/ltlibrary.am |1
lib/am
On Dec 25 2007 17:58, Jan Engelhardt wrote:
>in a simple Makefile.am with
>
> SUBDIRS = foo
> bin_PROGRAMS = bar
>
>how can I achieve that bar will be compiled before operation descends
>into foo/?
Nevermind, just found it in the info pages :)
Something as simp
Hi,
in a simple Makefile.am with
SUBDIRS = foo
bin_PROGRAMS = bar
how can I achieve that bar will be compiled before operation descends
into foo/?
thanks,
Jan
Hi,
in the testcase at http://jengelh.hopto.org/f/am.tar.bz2 ,
liba.la does not get installed. What is the cause of this and
how could I fix it?
thanks,
Jan
==
$ ./configure --prefix=$PWD/rt
$ make install
CC a.lo
CC b.lo
CCLD libb.la
CCLD liba.la
CC
On Aug 17 2007 22:48, Andreas Schwab wrote:
>Jan Engelhardt <[EMAIL PROTECTED]> writes:
>
>> is there any real difference between $(var) and ${var}, and is the
>> latter as much POSIX as the first?
>
>Depends on the context. For a shell there is a big difference be
Hi,
is there any real difference between $(var) and ${var}, and is the
latter as much POSIX as the first?
thanks,
Jan
--
On Aug 9 2007 19:08, NightStrike wrote:
>> Unfortunately, it does not seem like the directory is encoded into the
>> object file, hence automake will fail on me since it wants to use
>> hooks.o for both hooks.c files.
>>
>> Is it currently possible to make the directory part of the object name,
>>
Hi again :)
in a different project, I have a number of files that have the same
filename, but live in different directories, for example
project/module1/hooks.c
project/module1/m1.c
project/module2/hooks.c
project/module2/m2.c
etc.
project/Makefil
Hi,
I observe that automake gives programs inconsistent .o names. For
example:
Result when running make (beautified here):
Expected result:
CC fifo-unblock.o
CCLD fifo-unblock
CC fifo.o
CC launch.o
CCLD ccgfs-fifo
CC
101 - 150 of 150 matches
Mail list logo
