On Fri, 2004-12-24 at 22:03 -0500, Bill wrote:
> I'm at my wit's end. I've been banging my head against the wall with
> autotools for several months now, and with each turn I seem to meet trouble.
>
> Please see the attached tar.gz file. It contains my minimal testcase for
> the problem I'm havi
In the same place you subscribed to this list.
http://lists.gnu.org/mailman/listinfo/automake
Stephen
--
Stephen Torri <[EMAIL PROTECTED]>
In a project which I particpate with there are certain compiler flags
that need to be removed from the CFLAGS because they cause problems with
the compiled code.
For example if with a imaginary compiler I had the flags:
CFLAGS="-a -b -c d"
For a large part of the project the CFLAGS are fine but
On Tue, 2004-09-07 at 16:03, Alexandre Duret-Lutz wrote:
> >>> "Stephen" == Stephen torri <[EMAIL PROTECTED]> writes:
>
> [...]
>
> Stephen> bash-2.05b$ autoconf --version
> Stephen> autoconf (GNU Autoconf) 2.59
> Stephen> Written by Da
On Wed, 2004-09-01 at 17:17, Bob Friesenhahn wrote:
> On Wed, 1 Sep 2004, Stephen torri wrote:
>
> > Autoconf 2.59 doesn't work with automake 1.9 for some reason. I made
> > conftest.ac with only AC_INIT in it and ran autoconf manually it
> > completed fine with no e
Autoconf 2.59 doesn't work with automake 1.9 for some reason. I made
conftest.ac with only AC_INIT in it and ran autoconf manually it
completed fine with no errors. I did:
autoconf -o /dev/null conftest.ac
--
Results of doing ./configure:
checking whether autocon
I have upgraded to automake-1.8.3 and libtool-1.5.6 and still I am
running into trouble on my Gentoo box to get a library file to be
removed when I do make uninstall.
bash-2.05b$ sudo make uninstall
/bin/sh ../../../libtool-nofpic --mode=uninstall rm -f
'/usr/lib/xine/plugins/1.0.0/post/xineplug_
On Tue, 2004-08-17 at 10:55, Bob Friesenhahn wrote:
> On Tue, 17 Aug 2004, Stephen Torri wrote:
>
> > On Tue, 2004-08-17 at 10:09, Bob Friesenhahn wrote:
> >> This sounds like a bug in your old libtool. Your Automake is out of
> >> date as well.
> >
> >
On Tue, 2004-08-17 at 10:09, Bob Friesenhahn wrote:
> This sounds like a bug in your old libtool. Your Automake is out of
> date as well.
>
> Bob
The highest libtool that is available via the Gentoo portage system is
1.5.6. I will upgrade to that.
How is 1.8.3 an out of date automake as well?
When make installs a library via make install it gets place in the
correct location as a .so file. Yet when make uninstall is run it fails
to remove the .so file. The reason for the failure is that its looking
for the .la file and not the .so.
(Gentoo system)
libtool: 1.4.3-r4
automake: 1.8.3
auto
nd search for
Autoheader Macros. I believve AH_VERBATIM is the macro you want to use
for your header. Can you just post the WarpedConfig.h.in file? It would
be nice to see what is causing all the trouble.
Stephen
--
Stephen Torri <[EMAIL PROTECTED]>
write this autoconfigure.ac
> file that looks like (?) and let autoheader generate the .in file? If you
> have a quick pointer to where this is documented I would appreciate it.
info autoheader
Also look at "Configuration Header Files" section of 'info autoconf'.
Stephen
--
Stephen Torri <[EMAIL PROTECTED]>
d create WarpedConfig.h.in.
Autoconfigure script will take that file and the user configurations
chosen and generate the end result file WarpedConfig.h in src/warped
directory.
I hope this helps.
Stephen
--
Stephen Torri <[EMAIL PROTECTED]>
inst_HEADERS = bin_a.h
# We do install the bin_b.h to $(prefix)/include/fakelib
library_includedir=$(includedir)/fakelib
library_include_HEADERS = bin_b.h
# Same binary program
bin_PROGRAMS = reallyfake
# Same binary sources
reallyfake_SOURCES = soo.c foo.c rah.c
reallyfake_LDADD = -lfakelib
Step
at prints out a string. See your favorite hello
world code. Use automake and autoconf to build the program by creating a
simple Makefile.am and a configure.in.
Stephen
--
Stephen Torri <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
$(edit) $(srcdir)/sage.in > sage.tmp
chmod +x sage.tmp
mv sage.tmp sage
CLEANFILES = sage
--
Stephen Torri
GPG Key: http://www.cs.wustl.edu/~storri/storri.asc
signature.asc
Description: This is a digitally signed message part
I am looking for an example Makefile.am for installing python scripts.
The files I need to install are composed of module files and the main
"executable" as I call it.
Stephen
--
Stephen Torri
GPG Key: http://www.cs.wustl.edu/~storri/storri.asc
signature.asc
Description: This is a
On Mon, 2003-10-13 at 18:56, Tom Tromey wrote:
> >>>>> "Stephen" == Stephen Torri <[EMAIL PROTECTED]> writes:
>
> Stephen> TESTS = test_Foo
> Stephen> test_Foo_SOURCES = test_Foo.cpp
>
> As you discovered, you have to list test_Foo in a _PR
st
was able to go ahead. I am not sure this is the best semantics to get
the job doing. I am curious to hear opinions on this?
Stephen
--
Stephen Torri
GPG Key: http://www.cs.wustl.edu/~storri/storri.asc
signature.asc
Description: This is a digitally signed message part
_LIBS_PKGLIBS \
> $(MODULES)
>
> This will cause xyz.la and abc.la to be installed/uninstalled into/from
> $(pkgdatadir)/modules.
See my above comment about pkglibdir.
Thanks for the ideas Tom. I got want I wanted in the end. You helped me
remember the -avoid-version flag.
Stephen
--
Stephen Torri
GPG Key: http://www.cs.wustl.edu/~storri/storri.asc
signature.asc
Description: This is a digitally signed message part
"-g $wall"
MODULE_LDFLAGS="-export-dynamic -module -avoid-version"
For example, a module called libFS.la (Filesystem module) will produce
libFS.la and libFS.so in the installation directory. The only way that I
know to only see libFS.so in the install directory is to place a scr
igured with
@samp{--disable-shared},
! or if the host does not support shared libraries.
See the previous remark. Again it seems counter productive.
Stephen
--
Stephen Torri
GPG Key: http://www.cs.wustl.edu/~storri/storri.asc
signature.asc
Description: This is a digitally signed message part
problem.
Stephen
--
Stephen Torri
GPG Key: http://www.cs.wustl.edu/~storri/storri.asc
signature.asc
Description: This is a digitally signed message part
libraries are installed now to /usr/local/lib. So I
would want to do /usr/local/lib/PACKAGE_NAME/MODULE_TYPE. I hope that is
clear enough since I am writing this email being very tired.
Stephen
--
Stephen Torri
GPG Key: http://www.cs.wustl.edu/~storri/storri.asc
signature.asc
Description: This is a
I am on a project that would like to only install shared library files
(.so) but not the .la files. I tried to put AC_DISABLED_STATIC and then
AM_DISABLED_STATIC into the configure to do this. Neither declaration
worked. Is there a method for doing what we want?
Stephen
--
Stephen Torri <[EM
On Mon, 2002-11-18 at 10:20, Bruce Korb wrote:
> Stephen Torri wrote:
> >
> > On Mon, 2002-11-18 at 08:23, Earnie Boyd wrote:
> > > As long as the sub-project didn't have dependencies on the other parts,
> > > your sound developer should be able to configure
. If Z does have dependencies on other parts then make sure
> they're satisfiable via the generated makefile.
>
> Earnie.
How would you make sure that dependencies on other parts are satisified?
Stephen
--
Stephen Torri <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
Z' then it may take considerably
less time to build than a full make job. Directory 'Z' might only depend
on a few libraries in 'A', 'G' and 'R'. Four directories is nicer than
24 from a developers point of view.
I hope this explains what I am looking at f
On Mon, 2002-10-07 at 21:11, Tom Tromey wrote:
> >>>>> "Stephen" == Stephen Torri <[EMAIL PROTECTED]> writes:
>
> Stephen> In part of a project we generate code from an IDL
> Stephen> compiler. All we want to do is ensure that the files compile
In part of a project we generate code from an IDL compiler. All we want
to do is ensure that the files compile but we do not want to link
everything together to create an executable. Is it possible to stop
automake from invoking the linker for just one directory?
Stephen
On Mon, 2002-09-30 at 22:59, Tom Tromey wrote:
> `distcheck' will unpack your new tarball and try to configure and
> build it. Look in the unpacked directory. Is the `m4' subdirectory
> there?
Yes.
> If not, did you perhaps forget `SUBDIRS = m4'?
No. Its the second item in the list.
> Tha
Automake-2.54
Automake-1.6.3
When I can configure and compile a project that I am working on the
automake and autoconf files. When I run "make -j4" it works fine. But
when I try to do "make distcheck" I get back:
config.status: creating po/POTFILES
config.status: creating po/Makefile
config.stat
On Tue, 2002-09-10 at 01:06, Paul Smith wrote:
>
> Steve gave you the advantage: so you can run them individually.
>
> There are many compilers that won't accept linker flags (libraries,
> etc.) on a command line meant to compile a file (but not link it).
>
> The reason for having a separate CF
On Mon, 2002-09-09 at 23:11, Steve M. Robbins wrote:
> On Mon, Sep 09, 2002 at 10:33:40PM -0500, Stephen Torri wrote:
> > I am just posting this to make sure I understand the difference between
> > these:
> >
> > AM_CFLAGS - compile time flags
> > AM_CPPFLAGS
I am just posting this to make sure I understand the difference between
these:
AM_CFLAGS - compile time flags
AM_CPPFLAGS - preprocessor flags (e.g. -I, -D)
AM_LDFLAGS - linker flags (e.g. -L)
I am working on a project that is updating its Makefile.am files. I see
a variety of flags in one varia
On Fri, 2002-07-12 at 11:38, Tom Tromey wrote:
> >>>>> "Stephen" == Stephen Torri <[EMAIL PROTECTED]> writes:
>
> Stephen> I have my LDFLAGS variable set for a program as:
> Stephen> -L@top_srcdir@/src -lnestORB
>
> Use -L$(top_builddir)/s
the libnestORB.la when running "make distcheck" is:
/home/torri/src/nestROB/nestORB-0.51/=build/src
Is there something that I am doing wrong here? I do not want to declare
a bug if I am improperly using automake.
Stephen Torri
Running automake (CVS compiled) against my configure.in causes the
message "automake: configure.in: required file `master/depcomp' not found.
There is no mention to a file called "depcomp" in configure.in or
master/Makefile.am. In the master/Makefile.in there is mention to it:
depcomp = $(SHELL)
No problem. I will move the code into a user directory and work as my
normal user. In regards to install the "questionable" tarball, how do you
handle it? If my /usr/local/bin is owned by root then I cannot install it
as a normal user.
Stephen
On 20 Feb 2001, Akim Demaille wrote:
On 20 Feb 2001, Akim Demaille wrote:
>
> How frustrating not to see what failed...
>
> Could you try this:
>
> /tmp % touch foo nostromo 16:38
> /tmp % chmod 000 foo nostromo 16:38
> /tmp % cp -pR foo bar
Problem with install2.test
Here is the output from "make check TESTS='install2.test' VERBOSE=yes
---
Making check in .
make[1]: Entering directory `/usr/src/automake'
make[1]: Nothing to be done for `check-am'.
make[1]: Leaving directory `/usr/src/auto
On 20 Feb 2001, Akim Demaille wrote:
> Stephen Torri <[EMAIL PROTECTED]> writes:
>
> > On 20 Feb 2001, Akim Demaille wrote:
> >
> > > Huh??? What version of autoconf are you using? Could you try this?
> >
> > autoconf 2.94d
>
> You missed th
On 20 Feb 2001, Akim Demaille wrote:
> Huh??? What version of autoconf are you using? Could you try this?
autoconf 2.94d
> src/am/tests % make check TESTS=ansi3.test nostromo 15:45
---
Output of make check TESTS=ansi3.test VERBOSE=yes
---
On 20 Feb 2001, Akim Demaille wrote:
> Stephen Torri <[EMAIL PROTECTED]> writes:
>
> I personally observe no failure. Please, post the result of
>
> make check TESTS='ansi3.test install2.test pr87.test subobj3.test
> target-cfalgs.test' VERB
Downloaded the latest automake from CVS. Running "make" went fine. Ran
"make check" and got five errors:
ansi3.test
install2.test
pr87.test
subobj3.test
target-cfalgs.test
New to automake so I cannot point out the exact problem. Willing to assist
any way I can.
Stephen
45 matches
Mail list logo
