On 21/1/21 9:15 am, Zack Weinberg wrote:
Now we've all had a while to recover from the long-awaited Autoconf
2.70 release, I'd like to start a conversation about where the
Autotools in general might be going in the future. Clearly any future
development depends on finding people who will do the
On 20/02/11 06:10, Ralf Wildenhues wrote:
Hi Russell,
* Russell Shaw wrote on Mon, Feb 14, 2011 at 12:00:14AM CET:
I'd ask more about how the internals of ./configure and autoconf works.
Can you formulate more specific questions?
And questions on how to make bison get handled without being
On 14/02/11 05:12, Ralf Wildenhues wrote:
[ Cross post; Reply-To and Mail-Followup-To set. Please followup to
the automake list only, to avoid excessive spammage. Thank you. ]
Hello everyone,
I've been advertising debbugs before, I think we should be a good
example. So, two proposals:
On 20/11/10 06:10, MK wrote:
I have a FOSS project distributed by debian, and for quite I've been
using this in the Makefile.am under install-data-am:
-strip --strip-all $(bindir)/executable
Since I could not find a way to prevent the project being built -g, and
there is no need for this.
On 15/11/10 01:10, Ralf Wildenhues wrote:
Hello Russell,
* Russell Shaw wrote on Sun, Nov 14, 2010 at 02:49:07AM CET:
In a Makefile.in generated by automake 1.9.6, it defines
top_builddir ok, but builddir is used but not defined in there.
This causes problems, because the automake manual says
Hi,
In a Makefile.in generated by automake 1.9.6, it defines
top_builddir ok, but builddir is used but not defined in there.
This causes problems, because the automake manual says:
— Variable: builddir
Rigorously equal to ‘.’. Added for symmetry only.
Steffen Dettmer wrote:
On Mon, Mar 22, 2010 at 4:44 PM, Reuben Thomas r...@sc3d.org wrote:
Not true. automake does not have explicit support for building
programs with the host compiler when cross-compiling, but I
have done this successfully in the past when I needed precisely
to build a
Steffen Dettmer wrote:
* On Sun, Mar 21, 2010 at 10:27 AM, Ralf Wildenhues wrote:
noinst_PROGRAMS = unimain
unimain_SOURCES = unimain.c
unidata.tab.c: unimain$(EXEEXT) /usr/share/unicode/UnicodeData.txt
./unimain$(EXEEXT) $ $@
BTW, execution of built programs like this makes your
Hi,
I want the unimain program built first, then use it to generate
unidata.tab.c, which is then compiled and linked into librunicode.la
bin_PROGRAMS = unimain
unimain_SOURCES = unimain.c
lib_LTLIBRARIES = librunicode.la
librunicode_la_SOURCES = runicode.c runicode.h
Ralf Wildenhues wrote:
Hello Russell,
* Russell Shaw wrote on Sun, Mar 21, 2010 at 07:06:00AM CET:
I want the unimain program built first, then use it to generate
unidata.tab.c, which is then compiled and linked into librunicode.la
bin_PROGRAMS = unimain
unimain_SOURCES = unimain.c
Ralf Wildenhues wrote:
* Russell Shaw wrote on Sun, Mar 21, 2010 at 09:26:44AM CET:
Ralf Wildenhues wrote:
* Russell Shaw wrote on Sun, Mar 21, 2010 at 07:06:00AM CET:
bin_PROGRAMS = unimain
unimain_SOURCES = unimain.c
unidata.tab.c: unimain$(EXEEXT) /usr/share/unicode/UnicodeData.txt
Ralf Wildenhues wrote:
* Russell Shaw wrote on Sun, Mar 21, 2010 at 11:18:03AM CET:
Ralf Wildenhues wrote:
Use noinst_PROGRAMS instead of bin_PROGRAMS. Be encouraged to read the
fine manual.
But it is somewhat big, and i had already searched through the online
one a lot first
Alfred M. Szmidt wrote:
Have you tried reading `(automake) Autotools Introduction'? It is part
of the automake manual.
Hi,
I printed out all the autotools manuals and have read every page of
them more than once. It was a while ago, so it's easy to forget things.
Searching the online manual
Hi,
BUILT_SOURCES has no effect. gran.proc.tab.c should be built
first, but it doesn't happen. eerat isn't even run:
bin_PROGRAMS = appmain
appmain_SOURCES = appmain.c
nodist_appmain_SOURCES = gran.proc.tab.c
BUILT_SOURCES: gran.proc.tab.c
gran.proc.tab.c: gran.spec
eerat $ -o gran
Simon Richter wrote:
Hi,
On Fri, Dec 18, 2009 at 12:07:40AM +1100, Russell Shaw wrote:
BUILT_SOURCES: gran.proc.tab.c
BUILT_SOURCES is a variable, not a target.
Ok Thanks Simon. Should be '=' instead of ':'.
I knew that, but i didn't type what i mean ;)
Ralf Wildenhues wrote:
Hello Russell,
* Russell Shaw wrote on Fri, Jun 05, 2009 at 06:42:16PM CEST:
In my code that isn't installed, i dlopen my.so:
~/home/russ/myproj/src/libdir/my.so
When i make install, i want the dlopen to get my.so
from a system location:
/usr/lib/my.so
What make
Russell Shaw wrote:
Ralf Wildenhues wrote:
Hello Russell,
* Russell Shaw wrote on Fri, Jun 05, 2009 at 06:42:16PM CEST:
In my code that isn't installed, i dlopen my.so:
~/home/russ/myproj/src/libdir/my.so
When i make install, i want the dlopen to get my.so
from a system location:
/usr
Hi,
In my code that isn't installed, i dlopen my.so:
~/home/russ/myproj/src/libdir/my.so
When i make install, i want the dlopen to get my.so
from a system location:
/usr/lib/my.so
What make variable can i utilize that has a value
dependent on whether the package is installed or not?
Hi,
In /proj/keysyms, i have a Makefile.am and it generates a genkeysyms program
in C.
/proj/src contains a Makefile.am and it generates source files in this
directory using ../keysyms/genkeysyms, then uses these sources in the rest
of the compile.
/proj/src/Makefile.am has:
John Calcote wrote:
Russell,
On 4/1/2009 4:47 AM, Russell Shaw wrote:
...
proj/Makefile.am should contain:
SUBDIRS = ... keysyms ... src ...
Just makesure keysyms is given before src in that list.
Thanks, it works now:)
Bob Friesenhahn wrote:
On Wed, 10 Dec 2008, NightStrike wrote:
Ok, so again, I should be allowed to accept that *potential* risk as
being far less than the current situation of *actual* risk which is
causing problems. If I knew anything about Perl, I'd just do it
myself, but alas, the
Cédric Lucantis wrote:
Le samedi 04 août 2007, Russell Shaw a écrit :
Hi,
I'm using automake 1.9.6.
In automake.am, i have: CLEANFILES: *.tab.c *.tab.h *.tab.callback
However, in the generated makefile, CLEANFILES appears, but is not
referenced anywhere. Therefore, make clean doesn't work
Hi,
In automake.am, i have:
System_LTLIBRARIES = system.la
system_la_SOURCES = modules/System/system.c
system_la_LDFLAGS = -module
This compiles ok. However, it puts system.la in the top level src directory.
I want it to be like:
System_LTLIBRARIES = modules/System/system.la
Braden McDaniel wrote:
On Mon, 2007-08-06 at 03:49 +1000, Russell Shaw wrote:
Hi,
In automake.am, i have:
System_LTLIBRARIES = system.la
system_la_SOURCES = modules/System/system.c
system_la_LDFLAGS = -module
This compiles ok. However, it puts system.la in the top level src directory
Ralf Wildenhues wrote:
Hello Braden, Russell,
* Braden McDaniel wrote on Sun, Aug 05, 2007 at 08:27:07PM CEST:
On Mon, 2007-08-06 at 03:49 +1000, Russell Shaw wrote:
I want it to be like:
System_LTLIBRARIES = modules/System/system.la
modules_System_system_la_SOURCES = modules/System
Ralf Wildenhues wrote:
Hello Braden, Russell,
* Braden McDaniel wrote on Sun, Aug 05, 2007 at 08:27:07PM CEST:
On Mon, 2007-08-06 at 03:49 +1000, Russell Shaw wrote:
I want it to be like:
System_LTLIBRARIES = modules/System/system.la
modules_System_system_la_SOURCES = modules/System
Hi,
I'm using automake 1.9.6.
In automake.am, i have: CLEANFILES: *.tab.c *.tab.h *.tab.callback
However, in the generated makefile, CLEANFILES appears, but is not
referenced anywhere. Therefore, make clean doesn't work as it should.
Cédric Lucantis wrote:
Le samedi 04 août 2007, Russell Shaw a écrit :
Hi,
I'm using automake 1.9.6.
In automake.am, i have: CLEANFILES: *.tab.c *.tab.h *.tab.callback
However, in the generated makefile, CLEANFILES appears, but is not
referenced anywhere. Therefore, make clean doesn't work
Ralf Wildenhues wrote:
Hello Russell,
* Russell Shaw wrote on Sun, Sep 17, 2006 at 03:00:29PM CEST:
Does aclocal have a way to add m4 directories using an environment
variable?
AFAIK no, but you can add directories using the -I flag.
On debian, it only looks in /usr/share/aclocal. I want
Hi,
Does aclocal have a way to add m4 directories using an environment variable?
On debian, it only looks in /usr/share/aclocal. I want it to look in
/usr/local/share/aclocal too.
I couldn't find the source for aclocal in the automake tree.
Hi,
There is pkgdatadir, pkglibdir, and pkgincludedir.
Wouldn't it make sense to have a pkgsysconfdir too?
Ralf Wildenhues wrote:
Hello Russel,
* Russell Shaw wrote on Tue, Sep 05, 2006 at 04:21:20PM CEST:
What do i put into Makefile.am to get a program installed
into /usr/bin? (I just read the autoconf and automake manuals)
Nothing, you just
./configure --prefix=/usr
or, if you want only
Ralf Wildenhues wrote:
Hello Russel,
* Russell Shaw wrote on Tue, Sep 05, 2006 at 04:21:20PM CEST:
What do i put into Makefile.am to get a program installed
into /usr/bin? (I just read the autoconf and automake manuals)
Nothing, you just
./configure --prefix=/usr
or, if you want only
Hi,
I have lots of libraries and programs in separate directories, each
with its own configure.ac and Makefile.am.
What can i put into Makefile.am so that after each library is built,
it will copy its header file and object file to another directory in
the project tree?
I want all the library
Paul D. Smith wrote:
I'm still waiting for _ANY_ kind of response here.
Doesn't anyone know or care about config.guess or config.sub anymore?
From automake manual:
config.guess
config.sub
These programs compute the canonical triplets for the given build,
host, or target architecture. These
Hi,
In configure.am, i have:
AM_PATH_GTK_2_0(2.0.0,,,gthread)
AM_PATH_GLIB_2_0(2.0.0,,,gthread)
but i still get linker errors:
gcc -g -O2 -o iongen main.o gui.o eventfifo.o event.o xmalloc.o
-Wl,--export-dynamic -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0
-lgdk_pixbuf-2.0 -lm
36 matches
Mail list logo
