Re: unoconv listener in an automake file?
Paul Elliott pelli...@blackpatchpanel.com writes: unoconv is a program that converts openoffice any other documents to different formats. Its man page says it can use a listener: Example: unoconv --listener unoconv -f pdf some-document.odt unoconv -f doc other-document.odt unoconv -f jpg some-image.png unoconv -f xsl some-spreadsheet.csv kill -15 %- If the kill is left off, the listener continues even after the make completes and if debuild has started the make, it will hang untill someone kills the listener. ps -f shows that the listener has made the ppid=1 after the make completes. unoconv man page says that you can omit creating a listener in which case unoconv will create its own. I have never gotten this to work, and it will still have the problem of killing the listener afterwards. It sounds (from this message and from other replies) that this is not really trivial. So, I would write a separate shell script that does everything needed properly and invoke that from the Makefile. It's much easier, in my opinion, to write nontrivial bits of shell in separate scripts than to try to maintain them inside a Makefile. -- Ben Pfaff http://benpfaff.org
Re: Modify $PATH for all subdirectories
Too, Justin A. t...@llnl.gov writes: Thanks for the tips. I definitely would like to have the most portable solution so I'm leaning toward Dave's suggestion. The reason I wanted the PATH solution, however, was to keep things simple and in one location. Maybe what I will do is set an AC_SUBST for SOME_TEST, then in the check-local rules I can simply use: configure.ac: AC_SUBST(SOME_TEST, [$(top_builddir)/scripts/test/install/bin/something]) check-local: check-something check-something: @SOME_TEST@ --or --other Why use Autoconf for this? Just add a variable to Makefile.am: SOME_TEST = $(top_builddir)/scripts/test/install/bin/something check-local: check-something check-something: $(SOME_TEST) --or --other -- Ben Pfaff http://benpfaff.org
Re: Modify $PATH for all subdirectories
Too, Justin A. t...@llnl.gov writes: Can I define SOME_TEST in only one Makefile.am and make it available to all of the others? I have many Makefile.ams that require the SOME_TEST variable and I would prefer not having to define it in every Makefile.am individually. If I have it in one location, it provides me the flexibility to easily swap SOME_TEST = X or SOME_TEST = Y at a later stage if necessary. If you want SOME_TEST defined everywhere automatically, you should use configure.ac. As an alternative you can create a file of Makefile fragments and use the Automake include directive to include that in each of your Makefile.ams. Personally I prefer the latter. One sometimes-nice advantage is that modifying the include file requires only rerunning Automake, which is faster than rerunning Autoconf and Automake. -- Ben Pfaff http://benpfaff.org
Re: GSoC project idea: non-recursive automake project
Nick Bowler nbow...@elliptictech.com writes: * Modify gnulib so that it can be easily integrated into a non-recursive automake setup. One could look to libltdl for inspiration here. It doesn't have to be modified. An Automake setup can easily and usefully contain a mix of recursive and non-recursive subdirectories. -- Ben Pfaff http://benpfaff.org
order of variables and rules in output
In a Makefile, the relative order of variable and rule definitions matters, because variables used in targets are expanded when rules are read. If a variable is used in a target before the variable is changed, the variable's former expansion is used in the target, not the latter expansion. Current Automake appears to reorder the Makefile.am so that all variable assignments precede all rules, so in a Makefile.am the relative order of variable and rule definitions does not matter. Is this behavior documented? Is it guaranteed to remain in the future? I could not easily find mention of it in the manual, but it is sometimes convenient. Thanks, Ben. -- Ben Pfaff http://benpfaff.org
Re: Bug#565663: [PATCH] aclocal: Make missing 'dir' in -Idir a warning instead of a fatal error.
Ben Pfaff b...@cs.stanford.edu writes: +2010-02-27 Ben Pfaff b...@cs.stanford.edu + + Make -Idir a warning instead of a fatal error if 'dir' does not + exist. + * aclocal.in (scan_m4_dirs): Demote fatal error to warning. + I was hoping for some feedback on this proposed patch. -- Ben Pfaff http://benpfaff.org
Re: Public header files
Jef Driesen jefdrie...@hotmail.com writes: It works fine for every system I have access too, but long long is not standard and thus not guaranteed to be present. So I just want to make sure it will work on other systems too. long long has been standard for 11 years now. It is irritating that some vendors have apparently not updated their C compilers in that long. -- Ben Pfaff http://benpfaff.org
[PATCH] aclocal: Make missing 'dir' in -Idir a warning instead of a fatal error.
The process for bootstrapping some software from a version control system
checkout involves running aclocal before the m4 directory exists, then
populating the m4 directory and running aclocal again. This is what
happens with, for example, the tracker program that can be checked out
via git://git.gnome.org/tracker: removing the m4 directory from this
checkout (which was added as a dummy just to suppress this problem) and
running autoreconf -vfi will fail with a fatal error from aclocal:
autoreconf2.50: Entering directory `.'
autoreconf2.50: configure.ac: not using Gettext
autoreconf2.50: running: aclocal --force -I m4
aclocal: couldn't open directory `m4': No such file or directory
autoreconf2.50: aclocal failed with exit status: 1
With this commit, the autoreconf step can be completed.
This problem was reported by Michael Biebl bi...@debian.org as a bug
against the Debian packaging of Autoconf. The Debian bug log is available
at http://bugs.debian.org/565663.
---
ChangeLog |6 ++
aclocal.in |3 ++-
2 files changed, 8 insertions(+), 1 deletions(-)
mode change 100644 = 100755 aclocal.in
diff --git a/ChangeLog b/ChangeLog
index 5fbc889..d0d8ccf 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2010-02-27 Ben Pfaff b...@cs.stanford.edu
+
+ Make -Idir a warning instead of a fatal error if 'dir' does not
+ exist.
+ * aclocal.in (scan_m4_dirs): Demote fatal error to warning.
+
2010-02-24 Antonio Diaz Diaz ant_d...@teleline.es (tiny change)
Ralf Wildenhues ralf.wildenh...@gmx.de
diff --git a/aclocal.in b/aclocal.in
old mode 100644
new mode 100755
index dc84762..6d6156e
--- a/aclocal.in
+++ b/aclocal.in
@@ -311,7 +311,8 @@ sub scan_m4_dirs ($@)
{
if (! opendir (DIR, $m4dir))
{
- fatal couldn't open directory `$m4dir': $!;
+ msg ('unsupported', couldn't open directory `$m4dir': $!);
+ next;
}
# We reverse the directory contents so that foo2.m4 gets
--
1.6.5
--
...In the UNIX world, people tend to interpret `non-technical user'
as meaning someone who's only ever written one device driver.
--Daniel Pead
Re: using color-tests backwards-portably
Ralf Wildenhues ralf.wildenh...@gmx.de writes: I think Automake should provide an API to allow users to say if the Automake version is = X, then expand this configure.ac code. I think that would be general enough (it could use Automake conditionals to adjust Makefile.am files, it could check for = X and not = X+1 to enforce exact versions (or we could just provide a general version compare function) and it could then call AM_INIT_AUTOMAKE with the appropriate options). Also, it would be explicit enough for the developer to be conscious about not using this by accident. As an alternative, could Automake provide an API that allows users to say if feature X is supported, then expand this configure.ac code? For example: AM_FEATURE_PREREQ([color-tests], [AM_INIT_AUTOMAKE([foreign color-tests])], [AM_INIT_AUTOMAKE([foreign])]) This seems to me more in keeping with the Autoconf philosophy. -- Ben Pfaff http://benpfaff.org
Re: using color-tests backwards-portably
Ralf Wildenhues ralf.wildenh...@gmx.de writes: * Ben Pfaff wrote on Fri, Aug 14, 2009 at 06:33:14PM CEST: As an alternative, could Automake provide an API that allows users to say if feature X is supported, then expand this configure.ac code? For example: AM_FEATURE_PREREQ([color-tests], [AM_INIT_AUTOMAKE([foreign color-tests])], [AM_INIT_AUTOMAKE([foreign])]) This seems to me more in keeping with the Autoconf philosophy. Yes, the idea sounds better. But without also exposing something like AM_SET_OPTION, it would not scale: with the above, you might have exponentially many cases to cater to as user (e.g., 8 for 3 features, if you really want to be fully version-agnostic by ignoring that feature X was introduced after feature Y). Well, I suppose that something like this would work: AM_INIT_AUTOMAKE([foreign AM_OPTIONAL_FEATURE([color-tests])]) where AM_OPTIONAL_FEATURE expands to its argument if that feature is supported and to the null string otherwise. (I don't understand the m4 quoting rules well enough to know whether I have the quoting right here.) One major detail of this idea is that now, aclocal or the macro code supplied with Automake would need to know about the set of options that are supported. It doesn't do so now; only _process_option_list in lib/Automake/Options.pm used at automake run time knows. Also, the set of options isn't just a set of fixed strings, but includes some regexps. OK. -- Ben Pfaff http://benpfaff.org
Re: using color-tests backwards-portably
Ralf Wildenhues ralf.wildenh...@gmx.de writes: I think Automake should provide an API to allow users to say if the Automake version is = X, then expand this configure.ac code. I think that would be general enough (it could use Automake conditionals to adjust Makefile.am files, it could check for = X and not = X+1 to enforce exact versions (or we could just provide a general version compare function) and it could then call AM_INIT_AUTOMAKE with the appropriate options). Also, it would be explicit enough for the developer to be conscious about not using this by accident. As an alternative, could Automake provide an API that allows users to say if feature X is supported, then expand this configure.ac code? For example: AM_FEATURE_PREREQ([color-tests], [AM_INIT_AUTOMAKE([foreign color-tests])], [AM_INIT_AUTOMAKE([foreign])]) This seems to me more in keeping with the Autoconf philosophy. -- Ben Pfaff http://benpfaff.org
Re: using color-tests backwards-portably
Ralf Wildenhues ralf.wildenh...@gmx.de writes: * Ben Pfaff wrote on Fri, Aug 14, 2009 at 06:33:14PM CEST: As an alternative, could Automake provide an API that allows users to say if feature X is supported, then expand this configure.ac code? For example: AM_FEATURE_PREREQ([color-tests], [AM_INIT_AUTOMAKE([foreign color-tests])], [AM_INIT_AUTOMAKE([foreign])]) This seems to me more in keeping with the Autoconf philosophy. Yes, the idea sounds better. But without also exposing something like AM_SET_OPTION, it would not scale: with the above, you might have exponentially many cases to cater to as user (e.g., 8 for 3 features, if you really want to be fully version-agnostic by ignoring that feature X was introduced after feature Y). Well, I suppose that something like this would work: AM_INIT_AUTOMAKE([foreign AM_OPTIONAL_FEATURE([color-tests])]) where AM_OPTIONAL_FEATURE expands to its argument if that feature is supported and to the null string otherwise. (I don't understand the m4 quoting rules well enough to know whether I have the quoting right here.) One major detail of this idea is that now, aclocal or the macro code supplied with Automake would need to know about the set of options that are supported. It doesn't do so now; only _process_option_list in lib/Automake/Options.pm used at automake run time knows. Also, the set of options isn't just a set of fixed strings, but includes some regexps. OK. -- Ben Pfaff http://benpfaff.org
EXTRA_DIST respects Automake conditionals?
I was surprised today to discover that EXTRA_DIST respects Automake conditionals. In other words, if I have the following Makefile.am: AUTOMAKE_OPTIONS = foreign EXTRA_DIST = if COND bin_PROGRAMS = foo foo_SOURCES = foo.c EXTRA_DIST += EXTRA endif and configure.ac: AC_INIT([mumble], [1.0]) AC_CONFIG_SRCDIR([foo.c]) AC_CONFIG_FILES([Makefile]) AM_INIT_AUTOMAKE AC_PROG_CC AM_CONDITIONAL([COND], [false]) AC_OUTPUT then make dist will not put EXTRA into the generated tarball. It will put foo.c into the tarball, though. Is there an appropriate target to put files that should always be distributed, regardless of conditionals? noinst_HEADERS works, but to me it feels like abuse to use it for this purpose. For what it's worth, in the actual project where I encountered this, the usage is more like this: if ENABLE_USERSPACE ... include lib/automake.mk include ofproto/automake.mk include utilities/automake.mk include tests/automake.mk include include/automake.mk include third-party/automake.mk include debian/automake.mk include vswitchd/automake.mk include xenserver/automake.mk if HAVE_CURSES if HAVE_PCRE include extras/ezio/automake.mk endif endif endif In other words, I'm using a conditional to disable a great many features, and it's convenient not to push that conditional down into all the included files. Here's the Makefile.am in question: http://openvswitch.org/cgi-bin/gitweb.cgi?p=openvswitch;a=blob;f=Makefile.am;h=dccb8cfdf92a3dd4dc9f3276e7533f68769587f8;hb=c2b070214097fa40dc78252882d96babe7fab4b4 Thanks, Ben. -- Ben Pfaff http://benpfaff.org
Re: [Patch] New target to generate cscope database
Ralf Wildenhues ralf.wildenh...@gmx.de writes: Does cscope offer enough additional functionality over, say, Exuberant Ctags or gtags, to warrant being supported? Do many people use it? The most useful feature of cscope that is not in *tags (as far as I know) is that it maintains a list of source code locations where a given function is called. Sometimes that is more convenient than grep. -- Mon peu de succès près des femmes est toujours venu de les trop aimer. --Jean-Jacques Rousseau
Re: noinst_TEXINFOS
Stefan Bienert bien...@zbh.uni-hamburg.de writes: Could it be that a primary noinst_TEXINFOS does not work with automake 1.10.2? This seems likely. I reported the same problem some time ago: http://permalink.gmane.org/gmane.comp.sysutils.automake.bugs/4046 My report did not receive any replies. -- Ben Pfaff http://benpfaff.org
Re: automake not descending into subdirectories to create Makefile.in's
Laura Hughes (lahughes) [EMAIL PROTECTED] writes: My directory struct looks like this: topdir/ src/ src/basic_utilities src/ethernet_tests/bc5709_tests src/ethernet_tests/bc57711_tests src/mezzanine_card_tests [...] AC_CONFIG_FILES([Makefile basic_utilities/Makefile ethernet_tests/Makefile ethernet_tests/bc5709_tests/Makefile ethernet_tests/bc57711_tests/Makefile mezzanine_card_tests/Makefile]) It looks to me that there is a missing src/ at the beginning of most of those lines. -- I was born lazy. I am no lazier now than I was forty years ago, but that is because I reached the limit forty years ago. You can't go beyond possibility. --Mark Twain
Re: Feature request
Ralf Wildenhues [EMAIL PROTECTED] writes: * Akim Demaille wrote on Tue, Sep 23, 2008 at 04:35:50PM CEST: I'm slowly getting rid of my recursive Makefiles. Instead I have one local.mk per directory, and a few Makefile.ams that include them. Of course I have to prefix all my file names with the name of the directory, and I find that this explicit name is actually clutter. I don't think automake can be educated to guess by itself where to prepend the directory name, I would also find a feature to reduce this clutter useful. GNU PSPP in particular does not use recursive makefiles and has lots of directories. (Although PSPP uses the file name automake.mk instead of local.mk.) I don't have better syntax suggestions than yours or Akim's (unfortunately). Except: I'd really hate to invade make's namespace. They may come up with this really cool new makefile variable, and we can't use it then. :-/ I wonder whether this is a real issue, because Automake cannot really use new GNU make extensions anyhow (right?) because it writes out portable Makefiles. And it seems unlikely that POSIX would start inventing new Makefile syntax either. -- Unix... is not so much a product as it is a painstakingly compiled oral history of the hacker subculture. --Neal Stephenson
Re: Incorrect information in the manual about the tar-v7 option
Ralf Wildenhues [EMAIL PROTECTED] writes: * Vincent Lefevre wrote on Wed, Sep 17, 2008 at 06:09:43PM CEST: The automake manual (several versions) says about the tar-v7 option: `tar-v7' selects the old V7 tar format. This is the historical default. This antiquated format is understood by all tar implementations and supports file names with up to 99 characters. [...] Old versions of BusyBox (such as v1.6.1, currently used on Nokia's Internet tablets) don't support this format. See: [...] Should autotools add even more workarounds, or should rather simply BusyBox be fixed? If only old versions of BusyBox do not support v7 tar format, as Vincent implies, then BusyBox has already been fixed, and Nokia just needs to upgrade to a current version. -- Ben Pfaff http://benpfaff.org
Re: Incorrect information in the manual about the tar-v7 option
Ralf Wildenhues [EMAIL PROTECTED] writes: * Vincent Lefevre wrote on Wed, Sep 17, 2008 at 06:09:43PM CEST: The automake manual (several versions) says about the tar-v7 option: `tar-v7' selects the old V7 tar format. This is the historical default. This antiquated format is understood by all tar implementations and supports file names with up to 99 characters. [...] Old versions of BusyBox (such as v1.6.1, currently used on Nokia's Internet tablets) don't support this format. See: [...] Should autotools add even more workarounds, or should rather simply BusyBox be fixed? If only old versions of BusyBox do not support v7 tar format, as Vincent implies, then BusyBox has already been fixed, and Nokia just needs to upgrade to a current version. -- Ben Pfaff http://benpfaff.org
Re: best practice for injecting include dir across a project
Monty Taylor [EMAIL PROTECTED] writes: I've got a project that has 24 Makefile.am files. At the top of all of them at the moment, I've got: AM_CPPFLAGS = -I$(top_builddir)/include -I$(top_srcdir)/include I tend to write include $(top_srcdir)/Make.vars at the top of each Makefile.am, and then include common settings in Make.vars at the top of the source directory. -- It was then I realized how dire my medical situation was. Here I was, a network admin, unable to leave, and here was someone with a broken network. And they didn't ask me to fix it. They didn't even try to casually pry a hint out of me. --Ryan Tucker in the Monastery
Re: preprocessor output target
Jason Roscoe [EMAIL PROTECTED] writes: For example, if I have a source file called init.c, I would like to be able to type something like 'make init.i' and get the output of the preprocessor only (e.g., gcc -E). I sometimes do: rm init.o make CC='gcc -E' init.o mv init.o init.i -- Ben Pfaff http://benpfaff.org
Re: -local vs. -hook?
[EMAIL PROTECTED] (Karl Berry) writes: +In contrast, some rules also have a way to run another rule, called a [EMAIL PROTECTED]; these are always executed after their work is done. The The antecedents of these and their are slightly confusing here. I might reword it as: ...; hooks are always executed after the main rule's work is done. -- Ben Pfaff http://benpfaff.org
Re: Installing compressed info files
Bernd Jendrissek [EMAIL PROTECTED] writes: On Mon, May 26, 2008 at 9:29 PM, Ralf Wildenhues [EMAIL PROTECTED] wrote: Not all system's man programs cope with compressed manpages. I know some (most? all?) GNU/Linux distributions install compressed manpages, I assume it's rpm/deb/... features that compress them, right? I assume so too. I think non-archaic rpm has some nice macros that make building autoconfiscated packages easy. My bet would be that those rpm macros compress the docs. Similarly, the dh_compress program used in many Debian packages automatically finds and compresses any Info documents and manpages (and some other kinds of files) that are not already compressed. -- Ben Pfaff http://benpfaff.org
Re: BUILT_SOURCES doesn't seem to work
Bobby Dill [EMAIL PROTECTED] writes: pkgmaker_UI = sigcreatedlg.h sigcreatedlg.cpp One obvious error is here: the first two lines should end in \. -- [Modern] war is waged by each ruling group against its own subjects, and the object of the war is not to make or prevent conquests of territory, but to keep the structure of society intact. --George Orwell, _1984_
Re: It gits on my nerves
Ralf Wildenhues [EMAIL PROTECTED] writes: I work roughly similar. I hack away on a branch that contains all kinds of ugly and unfinished changes. Then to get more organized, I create another branch (off of master) and merge or cherry-pick the changes from the other branch. The git manual describes this in the creating the perfect patch series chapter. This works just fine, of course. Recently, I discovered the fairly new command git rebase --interactive, which can sometimes be even easier. You might check it out, if you are not already aware of it. -- Ben Pfaff http://benpfaff.org
noinst_TEXINFOS does not build Info files
With this Makefile.am: -- AUTOMAKE_OPTIONS = foreign noinst_TEXINFOS = foo.texinfo -- and this configure.ac: -- AC_INIT(amtest, 1.0, [EMAIL PROTECTED]) AM_INIT_AUTOMAKE AC_CONFIG_FILES([Makefile]) AC_OUTPUT -- and this foo.texinfo: -- @setfilename foo.info -- the generated Makefile.in will not build foo.info, either with make or make foo.info. However, if I change noinst_TEXINFOS to info_TEXINFOS, foo.info is built as expected. Is noinst_TEXINFOS unsupported? The manual says nothing about it as far as I can tell. I see a 5-year-old patch that would have added support for noinst_TEXINFOS: http://thread.gmane.org/gmane.comp.sysutils.automake.patches/191 It appears to have never been applied. -- Ben Pfaff http://benpfaff.org
Re: Circular dependencies and test programs
Michael B Allen [EMAIL PROTECTED] writes: But here's the problem: liba uses libtool / automake and builds a number of test programs not just by configure but by liba's test suite and the linker *does* try to resolve depenencies in that case. Meaning, if I try to build an executable with liba it says it needs libb but libb needs liba. So what do I do? Is there a way to tell configure don't build executables? If the test programs are listed on check_PROGRAMS, instead of on some other target, then they will be built only for make check, not for make all or make install. -- Ben Pfaff http://benpfaff.org
Re: Maintainer checks for non-c89 constructs?
James Youngman [EMAIL PROTECTED] writes: GCC accepts this construct because it is (or can be) a c99 compiler. I find that about twice a year someone submits a bug report because I've accidentally used a non-c89 construct without noticing. Is there any way I can use Automake to help me avoid this? For this particular problem, you can write an Autoconf test to check whether the C compiler accepts -Wdeclaration-after-statement and use it if so. In GNU PSPP we do it this way: dnl Check whether a C compiler option is accepted. dnl If so, add it to CFLAGS. dnl Example: PSPP_ENABLE_OPTION(-Wdeclaration-after-statement) AC_DEFUN([PSPP_ENABLE_OPTION], [ m4_define([pspp_cv_name], [pspp_cv_[]m4_translit([$1], [-], [_])])dnl AC_CACHE_CHECK([whether $CC accepts $1], [pspp_cv_name], [pspp_save_CFLAGS=$CFLAGS CFLAGS=$CFLAGS $1 AC_COMPILE_IFELSE([AC_LANG_PROGRAM(,)], [pspp_cv_name[]=yes], [pspp_cv_name[]=no]) CFLAGS=$pspp_save_CFLAGS]) if test $pspp_cv_name = yes; then CFLAGS=$CFLAGS $1 fi ]) PSPP_ENABLE_OPTION(-Wdeclaration-after-statement) -- Ben Pfaff [EMAIL PROTECTED]
Re: trying to find a good solution to filename clash
Russell Kliese [EMAIL PROTECTED] writes: If my makefile contains roughly the following: lib_LIBRARIES = libfoo.a libfoo_a_SOURCES = foo1/exception.cpp foo2/exception.cpp I end up with the following error: Makefile.am: object `exception.$(OBJEXT)' created by `foo2/exception.cpp' and `foo1/exception.cpp' I think that you want to put subdir-objects in your AUTOMAKE_OPTIONS. From the Automake manual: `subdir-objects' If this option is specified, then objects are placed into the subdirectory of the build directory corresponding to the subdirectory of the source file. For instance, if the source file is `subdir/file.cxx', then the output file would be `subdir/file.o'. In order to use this option with C sources, you should add `AM_PROG_CC_C_O' to `configure.ac'. -- Ben Pfaff [EMAIL PROTECTED] http://benpfaff.org
Re: RFC: Autotools Introduction chapter draft (16 pages long)
Alexandre Duret-Lutz [EMAIL PROTECTED] writes: Over the last weeks I've been writing an introductory chapter for the Automake manual. Now I could use some proofreading eyes, especially since I'm a foreigner. Other suggestions welcome too, of course. I'm always amazed how well people write English. My written French, for example, is miserable (although I can read French fairly well). I did a quick job of proofreading as I read your chapter. My thoughts are interspersed below. Today this process has been standardised in the GNU project. The GNU Coding Standards (*note The Release Process: (standards)Managin Managin - Managing Releases.) explains how each package of the GNU project should have package of the GNU project should have such a `configure' script, and Some words are repeated in the phrase above, messing up the grammar. the minimal interface it should have. The `Makefile' too should follow some established conventions. The result? A unified build system that makes all packages almost indistinguishable by the installer. In its most simple scenario, all the installer has to do is to unpack the most simple - simplest package, run `./configure make make install', and repeat with the next package to install. I'm never sure whether I should recommend running make before make install. make install will first build everything that make will, right? We call this build system the GNU Build System, since it was grown out of the GNU project. However it is used by a vast number of other packages: following any existing convention has its advantages. I would write , because instead of :, but this is at most a nitpick. The Autotools are tools that will create a GNU Build System for your package. Autoconf mostly focuses on `configure' and Automake on `Makefile's. It is entirely possible to create a GNU Build System without the help of these tools. However it is rather burdensome and error-prone. We will discuss this again after some illustration of the GNU Build System in action. 2.2 Use Cases for the GNU Build System == In this section we explore several use cases for the GNU Build System. You can replay all these examples on the `amhello-1.0.tar.gz' package distributed with Automake. If Automake is installed on your system, you should find a copy of this file in `PREFIX/share/doc/automake/amhello-1.0.tar.gz', where PREFIX is the installation prefix specified during configuration (PREFIX defaults to `/usr/local', however if Automake was installed by some GNU/Linux distribution it most likely has been set to `/usr'). If you do not have a copy of Automake installed, you can find a copy of this file inside the `doc/' directory of the Automake package. Some of the following use cases present features that are in fact extensions to the GNU Build System. Read: they are not specified by the GNU Coding Standard, but they are nonetheless part of the build system created by the Autotools. To keep things simple we do not make the difference. Our objective is to show you many of the features that make the difference - distinguish or perhaps point out the differences the build system created by the Autotools will offer to you. 2.2.1 Basic Installation The most common installation procedure looks as follows. ~ % tar zxf amhello-1.0.tar.gz ~ % cd amhello-1.0 ~/amhello-1.0 % ./configure ... config.status: creating Makefile config.status: creating src/Makefile ... ~/amhello-1.0 % make ... ~/amhello-1.0 % make check ... ~/amhello-1.0 % su Password: /home/adl/amhello-1.0 # make install ... /home/adl/amhello-1.0 # exit ~/amhello-1.0 % make installcheck ... Most of the time, when I see a shell example, the shell used in the example is the Bourne shell (hence a $ prompt). I don't know if it makes a difference to you or whether a reader could be confused by it. The user first unpacks the package, and then `cd' into the newly `cd' - `cd's created directory to run the `configure' script. This script probes the system for various features, and finally create the `Makefile's. In this toy example there are only two `Makefile's, but in real-world project there may be many more, usually one `Makefile' per directory. It is now possible to run `make'. This will construct all the programs, libraries, and scripts that need to be constructed for the package. In our example, this compiles the `hello' program. All files are constructed in place, in the source tree; we will see later how this can be changed. `make check' causes the package's tests to be run. This step is not mandatory, but it is often good to make sure the programs that have been built behave as they should, before you decide to install them. Our example does not contain any test, so
Re: Cover Texts in the automake documentation
Eric Dorland [EMAIL PROTECTED] writes: * Alexandre Duret-Lutz ([EMAIL PROTECTED]) wrote: Eric: | Is there any way you might consider dropping the | Front and Back Cover Texts requirements from the manual? Sorry, this is the FSF policy. Not my call. Could you please point out where the FSF have made this policy? http://www.gnu.org/prep/maintain/maintain.html#License-Notices Documentation files should have license notices also. Manuals should use the GNU Free Documentation License. Here is an example of the license notice to use after the copyright notice. Please adjust the list of invariant sections as appropriate for your manual. (If there are none, then say with no invariant sections.) See GNU Sample Texts, for a full example in a Texinfo manual. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with the Invariant Sections being GNU General Public License, with the Front-Cover Texts being ``A GNU Manual,'' and with the Back-Cover Texts as in (a) below. A copy of the license is included in the section entitled GNU Free Documentation License. (a) The FSF's Back-Cover Text is: ``You are free to copy and modify this GNU Manual. Buying copies from GNU Press supports the FSF in developing GNU and promoting software freedom.'' If the FSF does not publish this manual on paper, then omit the last sentence in (a) that talks about copies from GNU Press. If the FSF is not the copyright holder, then replace FSF with the appropriate name. -- On Perl: It's as if H.P. Lovecraft, returned from the dead and speaking by seance to Larry Wall, designed a language both elegant and terrifying for his Elder Things to write programs in, and forgot that the Shoggoths didn't turn out quite so well in the long run. --Matt Olson
Re: excessive bounces
I recommend reading the autoconf and automake lists via the NNTP
server at gmane.org, as the gmane.comp.sysutil.auto{conf,make}.*
groups. They filter spam for you and you don't have to screw
around with email subscriptions.
--
Implementation details are beyond the scope of the Java virtual
machine specification. One should not assume that every virtual
machine implementation contains a giant squid.
--Mr. Bunny's Big Cup o' Java
Re: Target-specific CFLAGS
Drummonds, Scott B [EMAIL PROTECTED] writes: From: [EMAIL PROTECTED] quote noinst_LIBRARIES = normal.a normal-feature.a normal_a_SOURCES = [bunch of files] normal_feature_a_SOURCES = $(normal_a_SOURCES) normal_feature_a_CFLAGS = -DFEATURE /quote ... Where have I gone wrong? Of course, when my source files are C++ files the _CFLAGS extension does nothing. Changing this to _CPPFLAGS fixed the problem. Duh. You know that CPPFLAGS is for the C preprocessor and CXXFLAGS is for the C++ compiler, right? -- Ben Pfaff email: [EMAIL PROTECTED] web: http://benpfaff.org
Re: Target-specific CFLAGS
Bob Friesenhahn [EMAIL PROTECTED] writes: On Tue, 24 Feb 2004, Ben Pfaff wrote: Of course, when my source files are C++ files the _CFLAGS extension does nothing. Changing this to _CPPFLAGS fixed the problem. Duh. You know that CPPFLAGS is for the C preprocessor and CXXFLAGS is for the C++ compiler, right? This distinction is not entirely correct since CPPFLAGS is normally supplied to the C++ compiler as well. CFLAGS is for the C compiler and CXXFLAGS is for the C++ compiler. Well, yes: C++ uses the C preprocessor. -- Ben Pfaff email: [EMAIL PROTECTED] web: http://benpfaff.org
Re: RFC: doc for `Handling Tools that Produce Many Outputs'
Alexandre Duret-Lutz [EMAIL PROTECTED] writes: This is a new section I'd like to add to the FAQ. It has been discussed two or three times on the list. It would be useful to have this in the Texinfo documentation for GNU Make, not just for Automake.
Re: coexist multiple versions of automake
Paul Lew [EMAIL PROTECTED] writes: Ben == Ben Pfaff [EMAIL PROTECTED] writes: Ben You may want to have a look at my packaging of Autoconf 2.13 Ben and Autoconf 2.52 for Debian, which includes an heuristic Ben that automatically picks the right version of Autoconf to run Ben in most cases. Thanks for the tip, but we are using Solaris. Do Debian package support multiple platform? The wrapper script is written in Perl. There's no reason you have to use the package itself; you could extract the script and use it by itself along with Autoconf 2.13 and 2.52 installs, if it turned out to be useful for your purpose.
Re: coexist multiple versions of automake
Paul Lew [EMAIL PROTECTED] writes: I would like to propose we modify automake (and autoconf) to allow multiple versions of automake coexisting on a given system. [...] You may want to have a look at my packaging of Autoconf 2.13 and Autoconf 2.52 for Debian, which includes an heuristic that automatically picks the right version of Autoconf to run in most cases. As for Automake, I don't know. I'm sure that other posters to this list will, though.
