Re: unoconv listener in an automake file?
Paul Elliott 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." 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.am"s. 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: Modify $PATH for all subdirectories
"Too, Justin A." 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: GSoC project idea: non-recursive automake project
Nick Bowler 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
Re: FW: Keep variable un-expanded in configure script
"Too, Justin A." writes: > However, Autoconf expands $#. How can I escape $#, so that it > will remain as-is in the configure script? I just can't figure > this one out :) $[#] or $[@%:@] will avoid expansion. (This is really an autoconf question.) -- Ben Pfaff http://benpfaff.org
Re: debbugs, and a FAQ, for Autotools
The question "libtool reorders link fags" seems to have a spelling error in the last word. It's not obvious to me what word is meant. -- 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: Public header files
Jef Driesen 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
Re: make clean is slow
Bob Friesenhahn writes: > Usually I don't care much about 'make clean' times but when I am > chasing down compilation warnings I tend to do a lot of cleans. When I'm chasing down compilation warnings I usually turn on "-Werror" temporarily. Saves a lot of time. -- Ben Pfaff http://benpfaff.org
Re: using color-tests backwards-portably
Ralf Wildenhues 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 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
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: noinst_TEXINFOS
Stefan Bienert 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: 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: 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_
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: 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 > b
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
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: Target-specific CFLAGS
"Drummonds, Scott B" <[EMAIL PROTECTED]> writes: > From: [EMAIL PROTECTED] >> >> 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 >> > ... >> 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: RFC: doc for `Handling Tools that Produce Many Outputs'
Akim Demaille <[EMAIL PROTECTED]> writes: > > Personally, I positively *like* "witness" - it describes what it is > > in a colourful way. > > For the records, this is the official English word for the same > concept in logic. A witness of an existential quantifier \exists > x. P(x) is precisely a t such that P(t). So I believe witness is > perfect for the current job. "Witness" is also used, sometimes, for the same purpose in descriptions of distributed filesystem commitment operations. I tried to look up a paper reference for this, but couldn't quite find it; I know I've seen it though. -- "I didn't say it was your fault. I said I was going to blame it on you."
Re: HATE
Dirk <[EMAIL PROTECTED]> writes: > Just look at debian they have now 3(!) different autoconf > versions because one works better or worse than the other. As the maintainer of Debian's Autoconf package, I'd like to let you know (1) we only have two versions--autoconf and autoconf2.13 and (2) most of the time the proper version should be selected automatically when you type "autoconf", as long as you install both versions. -- 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.
