Re: automatically showing test-suite.log on failure?

Bob Friesenhahn wrote: > Karl Berry wrote: > > However, this seems like it would be fairly commonly useful and easy > > enough to do in the canonical test-driver script. So, any chance of > > adding it as a standard feature? Any reasonable way of enabling it would > > be fine, e.g., a flag that can

Re: subscription issue

Hello Rudra, Rudra Banerjee wrote: > I am a subscriber of this list, but there is no post delevered in my > account. I also get a automake bounce notice, as > "Your membership in the mailing list Automake has been disabled due to > excessive bounces ..." > I tried to reply the mail as directed on

Re: AM_MAINTAINER_MODE

Russ Allbery wrote: > Bob Proulx writes: > > But another question to ask is if that is the case why not simply touch > > all of the files to the same time after the patching and before the > > make? That also forces everything to appear up to date too and doesn't > &g

Re: AM_MAINTAINER_MODE

Ineiev wrote: > Russ Allbery wrote: > >Another place where the default behavior frequently breaks is if one is > >applying a patch to both the generated file and the source file, usually > >because one explicitly *doesn't* want to re-run Automake (often because > >there's some incompatibility with

Re: execvp: /bin/sh: Argument list too long

Pippijn van Steenhoven wrote: > I am root on my (Linux) system and I set the stack size to unlimited. The > libtool macro reported a few billion (or something other really large) > for maximum argument list length, bash also agreed (it easily executed > the "distdir" target when copied into a bash

Re: Install to lib64

Jason Sewall wrote: > I'm maintaining an autotools-configured project, and I've noticed that > the make install resulting from my build (on x86_64 arch, linux) puts > generated libraries in prefix/lib instead of prefix/lib64 - is there > something I should do differently, or is the the expected beh

Re: automake distribution packages

[EMAIL PROTECTED] wrote: > This package is distributed as a tar.gz with no source files; only > binaries. Automake is written in Perl which are simply text files. The source and the executables are both the same. But if you are wishing to modify automake then working from the version control sou

Re: directory names with blanks break automake builds

Peter Simons wrote: > Bob Proulx writes: > > This is a documented limitation. See the following reference. > > > > > http://www.gnu.org/software/automake/manual/html_node/limitations-on-file-names.html#limitations-on-file-names > > I am sorry, but that pag

Re: directory names with blanks break automake builds

Peter Simons wrote: > I just ran across an interesting problem with automake 1.10. Just unpack > any other build into a directory called, say "/tmp/test automake", and > run it. In my particular case, the makefiles failed to call the local > copy of install-sh because of the blank. I checked my con

Re: flag question

Thomas Dickey wrote: > Bob Friesenhahn wrote: > > These options only work with GCC. If the compiler is GCC you can use > > them, otherwise skip them. > > The Intel compiler recognizes -Wall and -Werror (but not -pedantic in > the version I have at hand). The Intel compiler was actively trying t

Re: Report to stdout like Linux kernel compilation does

Ralf Wildenhues wrote: > For Emacs, all I know was that M-x compile did all that I ever needed. > But I'm sure it can be extended for unusual "compiler" output as well. For emacs use M-x compile to build. The default compile command is "make" but may be modified as desired. To walk through every

Re: Report to stdout like Linux kernel compilation does

Robert J. Hansen wrote: > John Calcote wrote: > > Hmmm. I'd have to disagree here. I carefully consider every warning I > > see, and evaluate whether or not it represents a real problem. > > Yes. This strikes me as perfectly sane behavior. I also agree with this. Using reasonable judgement is a

Re: Report to stdout like Linux kernel compilation does

John Calcote wrote: > I love this format because warnings and errors are obvious, and yet > you get enough output per file to tell you that something's going > on. To give you a different perspective, I *hate* that format because it hides problems and *makes debugging harder*. I want to see exact

Re: -lm -lz

Stefan Bienert wrote: > after an hour of searching, how am I supposed to invoke "-lm -lz" into > my compilation? The documentation states something about using "LIBS" as > a variable, autoconf also speaks of "LIBS" but nobody tells one what to > do with that variable. LIBS is inherited from aut

Re: proper autotools ordering?

Hi Karl! Karl Berry wrote: > I've been looking through the manuals and code, but not finding a > definitive answer: is there a canonical/recommended ordering of running > the autotools, including automake? I really like the encapsulation offered by 'autoreconf'. Bob

Re: make help?

NightStrike wrote: > I meant more along the lines of, for instance in the gcc project, > there is 'make all-gcc", "make all-gmp", "make all-mpfr", etc. Those are all custom local targets. The problem is the same as if I were Bilbo asking, "What do I have in my pocket?" It could be anything and n

Re: Building automake1.9 with autoconf2.61

Kamaljit Singh wrote: > I was hoping to create a src tree which would build automake1.9 and automake-1.9 has been replaced with automake-1.10.1. You should use the later version. ftp://ftp.gnu.org/gnu/automake/automake-1.10.1.tar.gz > autoconf2.61 and install them in a central place. Writing

Re: Automake (alpha) release request

Sebastian Pipping wrote: > Thanks for your replies! As I understood the Automake > release is delayed because its licensing info has not > been updated to GPLv3 yet? Actually the reverse. Because the licensing has already been updated it is now delayed. Automake installs auxiliary files into you

Re: Automake (alpha) release request

NightStrike wrote: > When you do make a release, where will be the list of new features located? The NEWS file is the standard location to list new features. The NEWS file as currently in version control can be seen here: http://git.sv.gnu.org/gitweb/?p=automake.git;a=blob;f=NEWS;hb=HEAD Bob

Re: What to check into repository?

Hongliang Wang wrote: > My company decides to make part of our software source code > open-sourced. For this part, we will use automake & autoconf tools > to generate the installation package (.tar.gz). That sounds wonderful! > However, the current problem is that we cannot decide what to check

failure in "colorful tests"

This following automake 'make check' finishes successfully. env TERM=ansi make -C tests check TESTS=color.test However this next one has a failure. env TERM=dumb make -C tests check TESTS=color.test And this one is quite colorful! :-) env TERM=dumb VERBOSE=yes make -C tests check TESTS=c

Re: Generating 'cat' pages on make install

Jason Curl wrote: > Continuing with my efforts of making a library designed for Linux a bit > usable for colleagues on Windows I'd like to figure out how to install > "cat" pages, i.e. conversions of "man" pages. Hmm... Would it make more sense to set up 'man' on ms-windows for your colleagues

Re: strange choice of compiler on HP-UX

Andreas Schwab wrote: > Joao Miguel Ferreira writes: > > Question: How do I tell the tools to use only aCC for both types of > > files, when compiling on an HPUX (we also build on Linux/gcc and > > Solaris/gcc) ? If the optional native HP ANSI C compiler is installed and 'cc' is a symlink to it th

Re: including files in the distribution tarball

James Willenbring wrote: > Some of our developers find it especially painful to list individual files. > Is there any way that we can add all files with a certain suffix to the list > of files that are included in our distribution by default, or even include > files that match some pattern? The st

Re: ${} and $()

Jan Engelhardt wrote: > is there any real difference between $(var) and ${var}, and is the > latter as much POSIX as the first? Is there any reason not to use $(var) and simply play it safe since that is the traditional Unix make behavior? Then all worries about whether the builder's make will h

Re: need help in "deep" project ..

Ralf Wildenhues wrote: > * Roberto Alejandro Espí Muñoz wrote: > > AC_INIT([/src/main.cpp]) > > Also note that there is a new form of AC_INIT/AM_INIT_AUTOMAKE, > used and explained in the manual: > To give an example, try using this in

Re: Automake violations of the gnu coding conventions

Are we talking about one of your own projects? Or are we talking about other projects that you are trying to build? K. Richard Pixley wrote: > Bob Proulx wrote: > > Someone who is simply building from the generated Makefiles never > > needs to have automake installed. Only a d

Re: Automake violations of the gnu coding conventions

K. Richard Pixley wrote: > I notice that automake is currently generating Makefiles that violate > the gnu coding conventions. Hmm... I don't think that automake violates the standards. In the normal case it is not required to have automake installed. Someone who is simply building from the ge

Re: Circular dependecy linker trouble

Søren Boll Overgaard wrote: > Hello, > > I've recently migrated a rather large body of code from a proprietary > development environment, to an automake based one. > > I've run into trouble during linking though. The code is laid out like > this: > > src/ > Contains main.cpp which holds the m

Re: Placing libraries in single central directory

antoon wrote: > By default this library is placed in the same directory as the C-files. After the result of 'make' yes. > But ... how to copy this library afterwards to a general *lib* directory, > because during the overall linkage step of my code, I want all my libraries > in one single direc

Re: Shouldn't the definition of maintainer-clean be changed?

Hello Stepan, Apologies to all for continuing the large crossposting. I am not subscribed to those lists. Stepan Kasal wrote: > For details, see my post here: > http://lists.gnu.org/archive/html/autoconf/2007-03/msg00043.html > > But people tend to guess that this target must be the opposite to

Re: generated ChangeLog

Stepan Kasal wrote: > Andreas Schwab wrote: > > If you use AUTOMAKE_OPTIONS = foreign then automake should not complain. > > yes, this is good note, thanks. I wanted to keep the gnu strictness, > since I hoped Automake would also check other things for me. > > But perhaps this is the best soluti

Re: Wishlist: Clean target for generated C files?

Ralf Wildenhues wrote: > * Bob Proulx wrote on Thu, Mar 01, 2007 at 05:37:56PM CET: > > With a use model more like this somewhat stylized example. > [...] > > ...modify code generator... > > make moreclean > > make > > Looks to me like if your genera

Re: Wishlist: Clean target for generated C files?

Perrog wrote: > 2007/2/28, Bob Proulx <[EMAIL PROTECTED]>: > >I would really like a clean target that would remove generated source > >files such as generated .c and .h files. In the case of yacc and lex > >I would like to distribute the generated files so as not to req

Wishlist: Clean target for generated C files?

I would really like a clean target that would remove generated source files such as generated .c and .h files. In the case of yacc and lex I would like to distribute the generated files so as not to require the use of yacc and lex to compile the distribution. This rules out DISTCLEANFILES or that

Re: init.d script best practice

deckrider wrote: > Is there a best practice example for using autoconf/automake to > install system init scripts? For instance, HP-UX looks for these in > /sbin/init.d and /sbin/rc*.d and many others look to /etc/init.d and > /etc/rc*.d. I would recommend not using automake for this. The format

Re: How do I write a configure.ac file to default sysconfdir to /etc?

Jim Lynch wrote: > I'd really like a way to enable this for specific applications, not > as a site default. ... ... ... If not, I'll just have to go back to > my cludgy way of adding my own rules to copy it to a hard coded > /etc, (Ugh). What I do is to keep a configure.sh script in the parent di

Re: Multiple lex scanners? How?

Nicolas Joly wrote: > Bob Proulx wrote: > > What is the best practice for organizing a program that includes > > multiple lex generated scanners? > > I encountered the same problem ... and made the following constructs > that did the trick (at least for me). > > AUT

Multiple lex scanners? How?

Multiple flex generated scanners are giving me trouble with duplicate symbols. I am using automake-1.10. What is the best practice for organizing a program that includes multiple lex generated scanners? I am using the recommended practice of using defines to rename all of the yacc/lex symbols as

Re: verbosity

Jason Kraftcheck wrote: > This makes it *very* easy to miss potential important compiler warnings > and such in all the noise. I have heard this infrequently from posters but I don't experience this myself and here is why. I think I will go out on a limb and say that most (many?) developers use

Re: c++ link order problems

Dan McMahill wrote: > Ralf Wildenhues wrote: > >Just curious: what's the reason for the ordering constraint? > > When static objects use inheritance, the base class must be initialized > before anything can be derived from it. At least that's what I've been > told. On this particular project,

Re: [automake] Debian and its alternatives' system.

Benoit Perrot wrote: > On debian, several version of the same package may be installed, > and the default, prefered one is selected by providing a > symbolic link pointing to it. Yes. Very nice. > So, I was wondering if there was a way to select the automake > path or exe to use, or if patching

Re: Forcing static link of libstdc++

Mike Melanson wrote: > Sounds like a useful possible solution. However, what if the primary > functionality actually resides in a shared library itself? As shown by ldd on the shared library? Those will be loaded using LD_LIBRARY_PATH so in that case you don't need the complicated wrapper for li

Re: Forcing static link of libstdc++

Mike Melanson wrote: > It's possible that I'm chasing after the wrong solution. This is a more > specific problem: > > * I have a proprietary program that I am trying to build to run on a > wide variety of Linux/x86-based distributions. > > * The build process links against libstdc++.so.6 on th

Re: config.guess comments from our sysadmins

Bob Friesenhahn wrote: > It may be considered a good thing to some, but it is not necessarily a > good thing. Consider that the rest of the build package (e.g. > libtool) is expecting particular host identifications and that > sometimes the behavior of these scripts change. Only very rarely wi

Re: config.guess comments from our sysadmins

Ralf Wildenhues wrote: > * Ed Hartnett wrote: > > Ralf Wildenhues writes: > > > It's safe to just replace the two files with newer versions; I think you > > > should keep the two in sync though. I thought I would note that both Debian and Red Hat packaging of programs that use config.guess and con

Re: (Slightly OT) including svn revision in config.h

Jim Lynch wrote: > Does anyone have a suggestion as to how I can automatically keep the svn > revision number in a config file somewhere? http://subversion.tigris.org/faq.html#version-value-in-source Bob

Re: Filename extension guidelines and man page symlinks

Roy Hills wrote: > I have two questions, which I hope that someone can help me with: > > 1. Are there any guidelines on file naming conventions for Perl scripts? > > In particular, should it be called "foo.pl", or just "foo"? Currently, I'm > using the latter naming convention, and include them

mailing list administrivia (was: aclocal 1.9.6 and drive letters)

Ralf Wildenhues wrote: > * Andreas Büning wrote: > > Some weeks ago I sent a mail to the automake-patches mailing list > > but it never appeared there. Then I tried the bug-automake > > mailing list. I checked the mailing list archives on lists.gnu.org > > my posting never appeared. > > That is we

Re: dynamic dist?

Hi Ralf, Ralf Wildenhues wrote: > Hi Bob, > > * Bob Proulx wrote on Sun, Apr 23, 2006 at 05:35:23PM CEST: > > > > If you consider POSIX systems as being portable enough then using > > the [:space:] character class should work pretty well. > > Thanks to Mr. S

Re: dynamic dist?

Ralf Wildenhues wrote: > Tyler MacDonald writes: > > OK, so I might need something more portable than cpio... but the > >"\s.*" part does serve a purpose; the MANIFEST file format allows for a > >description of the file after whitespace. I guess I could do "[ \t]" or > >something else instead o

Re: Broken makefile given Autoconf version mismatch

Noah Misch wrote: > Alexandre Duret-Lutz wrote: > > I'm leery of assuming that Autoconf's version will always be at > > this spot in the output of --version. Sometimes people customize their > > copy and tweak --version to reflect so: > > ... > > % gcc --version > > gcc (GCC) 4.0.3 (Debian 4.0.3-1

Re: how to something from the configure script into one of the test programs?

Ed Hartnett wrote: > To accommodate this on machines with disk quotas, I want to allow the > user to specify to configure a directory in which large files can be > created during testing. You might look into just having the user set TMPDIR (or through your configure option) to the directory for h

Re: libdir on x86_64

Ralf Wildenhues wrote: > * Guillaume Rousse wrote: > > Am i supposed to manually set libdir according to build host to get > > compliance with such constraint ? > > Yes, you can specify --libdir at configure time. Note for system > installations you will usually have to set more options, for > ex

Re: release and test targets

Ralf Corsepius wrote: > Baurzhan Ismagulov wrote: > > release: > > $(MAKE) CFLAGS=-O2 prefix=/usr sysconfdir=/etc localstatedir=/var > > You are miss interpreting automake's tasks. Packaging is not of > automake's business. The above technique really has nothing to do with automake and jus

Re: make depend problem with hello_SOURCES = ${SRCDIR}/hello.c

Harald Dunkel wrote: > Question about make depend: > > If I set > > SRCDIR = ../src > noinst_PROGRAMS = hello > hello_SOURCES = ${SRCDIR}/hello.c Shouldn't you be using normal VPATH? That is, you are setting hello_SOURCES = ../src/hello.c. But I don't think you want to do tha

Re: 'make' reruns configure ?!

Kendrick Smith wrote: > Can anyone tell me why an Automake-generated Makefile > would rerun the 'configure' script when 'make' is invoked, This would mean that the timestamps on the files indicate that you have modified a source file such as modifying a Makefile.am. Because the Makefile.am is new

Re: Atomic control of subdirectories with recursive automake

Brian wrote: > I wanted to be a little more clear on this (since you brought up the idea of > subdirectories I have become keen on it) Actually it was you who brought up the question of did it work in subdirectories. > Suppose I wanted to make two versions of hello - one in /src/hello and one >

Re: Atomic control of subdirectories with recursive automake

Brian wrote: > I am in the planning stages of autoconfiscating a large project. The project > will have a top-level makefile.am and then several Did you expect that to be a http web link? > subdirectories which each generate an executeable and have a > makefile.am

Re: back to directory dependencies

Baurzhan Ismagulov wrote: > [This thread was started on Jun 7. I couldn't find the list archive -- > http://directory.fsf.org/GNU/automake.html doesn't mention any, and > http://sources.redhat.com/ml/automake/2005-06/ says there were no > messages sent this month. Which archive do you use?] In the

Re: .DELETE_ON_ERROR ?

Stepan Kasal wrote: > Makefile.am contains: > > foo.h: foo.x > $(GENERATOR) foo.x >foo.h > > But the GENERATOR command failed and I have empty foo.h. Yes, because the shell redirection creates the file instead of the generator. > It would be nice if make deleted foo.h automatically, but t

if 'missing makeinfo' then pkg.info is zero sized

It seems that if 'makeinfo' is missing from the system but that the timestamp of the .texi file is newer than the .info file that the .info file is removed and replaced with a zero size file. I tested this with automake 1.9.5. I am trying to understand why what is happening is happening. I was l

Re: Automake and bison/flex sources

Oliver Boris Fischer wrote: > my project contains of some bison and flex files. It seems so, that > automake will distribute the genrated c files. > > Is this intended? How can I turn this off without abusing CLEAN_FILES > and co? Yes, that is intentional. The documentation for automake says:

Re: libtool non standard library name

Jean-Denis Giguere wrote: > pymod/Makefile.am:4: `_gtkmissing.la' is not a standard libtool library name > [...] > The pygtk-2.4.0 use this kind of configuration and it works well. > > I would really appreciate if someone may point me a document where I can > find more informations about this prob

Mailing list CC's

Here is a message I recently sent to an individual after observing that they never CC'd the original poster. This seemed topical after reading today's discussion. Bob Thanks very much for answering questions on the mailing lists. It is appreciated. However I noticed today that you have not be

Re: CCing list replies (was: Configuring automake says autoconf 2.58 or higher needed. Have au toconf 2.59 installed. What is/goes wrong?)

In this case I looked at the list of people in the discussion, knew they were all subscribed, and intentionally mailed only to the list. ;-) Andreas Schwab wrote: > Ralf Wildenhues <[EMAIL PROTECTED]> writes: > > This is not addressed at me, but I also had to learn the hard way > > that > > - some

Re: Configuring automake says autoconf 2.58 or higher needed. Have au toconf 2.59 installed. What is/goes wrong?

Thomas Dickey wrote: > Ralf Corsepius wrote: > > I normally respond CC:-ing the reporter on auto*.gnu.org lists, because > > they tend to be unreliable. Not have done so in this case was just an > > oversight. > > otoh, when I do that, I usually get 2-3 complaints from people stating > that I shou

Re: Disabling optimization

Bob Friesenhahn wrote: > Andrew Suffield wrote: > >>>What you're all trying to say is this: > >>> > >>>CXXFLAGS="-g -O0 ${CXXFLAGS}" > >>Nope, this prevents overriding CXXFLAGS from the environment. > > > >It does not. I do it all the time. On HP-UX: aCC -O0 aCC: warning 901: unknown option:

Re: automake during development

Jonathan wrote: > My team is trying to use automake for a C++ project we are developing. > The project design has been changing rapidly and we are finding that > keeping the list of source files in Makefile.am up to sync with the > contents of the directory is very inconvenient. > > An ideal solu

bug-automake address (was: aclocal.test failure)

Alexandre Duret-Lutz wrote: > Please do direct bug reports to [EMAIL PROTECTED], a spurious > failure of CVS Automake is noise for [EMAIL PROTECTED] There is no mention of bug-automake on the web page. http://www.gnu.org/software/automake/ Could one be added? Here is a proposed patch against

Re: can't login to list

r43233 wrote: > I have subscribed to the list but can't login. I have registered and > recieved confimation. However during confirmation i forgot to enable > cookies and the system won't allow me to login. I have enabled cookies > and exited mozilla and restarted it but still can't login. > rega

Re: package creation

Gustavo A. Baratto wrote: > Basically, what I looking for is a 'make package' rule, where all > the files that would be installed, plus an install script could be > tarred up together, so we can copy the tarball to many diferent > servers, unpack it, run the script, and the files get installed > wi

Re: library name enforcement?

Alexandre Duret-Lutz wrote: > >>> "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes: > > Ralf> On Mon, 2004-05-03 at 06:52, Bob Proulx wrote: > >> Older versions of automake allowed arbitrary library names. > >> > >> noin

Re: excessive bounces

Jay West wrote: > You should have sent this to the list owner/admin, not the list. Yes. But the list owner for the automake list is gnulists-ownrr at gnu.org, which is to say, effectively nobody. The list is really running entirely on inertia. For example there are over a hundred messages in th

Re: library name enforcement?

Dale E Martin wrote: > Bob Proulx wrote: > > Makefile.am:2: `foo.a' is not a standard library name > > Does this work? > foo_a_LDFLAGS=-module No. I get the same result. I am glad it did not work. It would have been just too strange. Thanks for making the suggestion just the same. Bob

library name enforcement?

Older versions of automake allowed arbitrary library names. noinst_LIBRARIES = foo.a Recent versions of automake now complain about this naming. Makefile.am:2: `foo.a' is not a standard library name I would normally like the lib naming but in this case I am retrofiting an existing project a

Re: Problem with configure

Priit Voolaid wrote: > i don't know is this the right place to ask my question. If not, sorry. [EMAIL PROTECTED] would have been better than [EMAIL PROTECTED] This has little to do with automake. > I want all the necessery files to go in /opt directory, so i execute > configure with --prefix=/op

Re: about requiring Perl 5.6 in Automake 1.9

Alexandre Duret-Lutz wrote: > Perl 5.005_03 will be 5 years old next month, and supporting it > is becoming painful. I sympathize. But actually the problem is not the age of the old version of perl is but rather youth of the new version. The new version has not yet propagated yet. But let me pr

Re: find a header file

Yanfeng Zheng wrote: > There was a problem when i compiled my program on red hat linux > 8.0. The error message was that the header file was > needed. Where can i get file? Thanks a lot. Your question has nothing to do with automake. Why ask it here? There is no standard header . If someone i

Re: 1.8 and mkdir_p

Harlan Stenn wrote: > > > I think you are missing my point. > > > The information I am talking about is used for *runtime* decisions - very > > > likely in a script that is in a shared directory used by many different > > > architectures. If for use at runtime then config.guess is very poorly suit

Re: config.guess and freedom (was: 1.8 and mkdir_p)

Harlan Stenn wrote: > The good news and bad news is that your position is a POLICY decision. > > I am talking about a MECHANISM tool. Agreed. But it is not a mechanism of automake. Nor should the autotools support it since it embodies a diametrically opposed philosophy from the one the autotool

Re: GNU Automake 1.7.9 released

Alexandre Duret-Lutz wrote: > > Charles Wilson writes: > Chuck> What is this "Autoconf 2.59" of which you speak? I saw this > > I'm using the AUTOCONF-2_59 tag from CVS. I didn't know it > hasn't been announced yet. All I can say is that Akim is away > today and tomorrow, so you'll have to wait

Re: Putting intermediate files in the distribution?

Paul Brook wrote: > > I have been thinking I should put the generated .c and .h files into > > both EXTRA_DIST and MAINTAINERCLEANFILES. > > Putting the files into BUILT_SOURCES should do what you want. This includes > them in the distribution, and removes them when you do "make > maintainer-cle

Putting intermediate files in the distribution?

I am autoconfiscating a moderately large legacy project. A previously existing methodology in the project is to create a large number of .c and .h files by generating them with a script from a template. I have created custom rules to do this and all builds fine. I originally put the generated fi

Re: making script executable?

Simon Richter wrote: > > $(SHELL) ? [Drifting off topic...] Does that mean that a SHELL=/bin/csh user will run the script with csh and a SHELL=/bin/zsh user will run the shell with zsh? Wouldn't it be better to use a predictable and most likely a standard shell for both users? /bin/sh "your

Re: weird flags set by configure

Earnie Boyd <[EMAIL PROTECTED]> [2002-11-07 11:39:37 -0500]: > [EMAIL PROTECTED] wrote: > >Otherwise, I'm also subscribed on the list, so no need to CC me in every > >post :-) Then set M-F-T in your postings. Mail-Followup-To: [EMAIL PROTECTED] > It is a function of the mail client "Reply-All"

Re: weird flags set by configure

[EMAIL PROTECTED] <[EMAIL PROTECTED]> [2002-11-04 12:43:48 +0200]: > Small question: > > Why do my autoconf-generated configure scripts automatically fit in > debugging info "-g -O2" (or -g if I ask nicely?) > When I compile release versions of my code, how do I (elegantly) ask > automake, or rath

Re: [Fwd: Re: X11 and configure.in]

Lars Hecking <[EMAIL PROTECTED]> [2002-10-30 10:36:09 +]: > Well, I'm using AC_PATH_X but I don't know how to use this in the > Makefile.am , I have tried to get it to work with : > > LDADD = -lX11 -lm -L$(x_libraries) For one thing you need to place all of your -L options before

Re: beginners question ?

Lars Segerlund <[EMAIL PROTECTED]> [2002-10-28 17:14:18 +0100]: > > I'm just starting to use gnu autotools, and I have some small > problems, I have figured out how to build in some subdirs and to > have resonable include paths, but how do I link with X11 , I'm using > automake and autoconf and h

Re: files left after distclean: How to clean those?

Bruce Korb <[EMAIL PROTECTED]> [2002-08-19 13:51:40 -0700]: > Do you distribute example.8? I could go either way. Let's say no. > If not, add it to the DISTCLEANFILES, That worked! Thanks! So now my Makefile.am looks like this. Anything flagrantly wrong? Otherwise this is working for me. T

files left after distclean: How to clean those?

I am wanting to use help2man to produce the man page for a program. I have a Makefile.am with the following. dist_man_MANS = example.8 example.8: src/example help2man --output=example.8 ./src/example But when I run 'make distcheck' I get the following error. Error: files left a

Re: spam hell

> It is possible to set up moderation. Actually, moderation is a wrong > word. The only responsibility of the moderator show be preventing spam. I help moderate a few of the GNU lists which are moderated solely to prevent spam and I can tell you from personal experience that it is a pain. Mai

Re: aclocal -I

Lars> It would be great if one could add -I options to aclocal by just placing Lars> macros in configure.ac, like: Lars> AC_CONFIG_MACRO_DIR(conf/m4macros) I would like that too. Tom> You can use ACLOCAL_AMFLAGS (bad name, I know) in Makefile.am. Uh, like this?: ACLOCAL_AMFLAGS = -I config

Re: Automake release

Random thoughts on version numbers... > to do this with automake since I've been saying for a long time "1.5 > will do this", "1.5 will do that". Bleah, my bad. > Agreed. Buuut... 1.4a-p1 seems wrong if HEAD is at 1.4c. Worse, releasing > 1.4b-p1 sounds like it is related to 1.4b. I still d

file D left after automake configure test

is is where I am stopping for the night and wanted to report this minor problem. This appears to be a spurious result as to all other intents and purposes everything configures and works well from this point on. BTW... I like the new dependency code! I can now swap between HP-UX ANSI C and Linux GCC interchangeably. Bob Proulx