I've been working recently on making automake create plain Makefiles
when it is run, rather than Makefile.in's, and thought I would share
my progress and thoughts on this.
The Makefile would trigger configure to be run when it is run for the
first time, eliminating the need for both "./configure"
On Sun, Apr 28, 2013 at 8:50 PM, Marko Kreen wrote:
> On Wed, Apr 24, 2013 at 12:10:44AM +0100, Gavin Smith wrote:
>> In the long run I'd like to see creating and running a build system to be
>> as simple as doing something like
>>
>> $ echo >Makefile.am <&
On Wed, Apr 24, 2013 at 12:10 AM, Gavin Smith wrote:
> I've been working recently on making automake create plain Makefiles
> when it is run, rather than Makefile.in's, and thought I would share
> my progress and thoughts on this.
>
>...
>
> I haven't included
On Tue, May 7, 2013 at 5:12 PM, Rhys Ulerich wrote:
> I gather that 'make install-strip' installs and then strips binaries.
> Is there some variant that reverses the order? If not, any
> recommendations for how to write one in an Automake-compliant manner?
>
> My unstripped binaries are absurdly
On Mon, Apr 29, 2013 at 8:16 PM, Bob Rossi wrote:
>
> Autotools is a great build system. However, after configuring it to
> place as many files as possible in a subdirectory, it still takes up
> 87.5% of my projects root directory.
>
> aclocal.m4
> autom4te.cache
> build
> configur
On Thu, May 23, 2013 at 12:46 AM, Jordan H. wrote:
> I'm using mysql in a program. Here is a snipped of my Makefile.am:
>
> project_LDADD += -lboost_thread
> project_LDADD += -lboost_regex
> project_LDADD += -lboost_system
>
> AM_LDFLAGS = -L/usr/local/lib
> AM_LDFLAGS += `mysq
>
> Alright, cool. I can get used to this syntax. How does autoconf know
> what SOME_MACRO is and how to use it in generating a `configure`
> script? I found a list of configure.ac macros in the automake manual
> (the auto*conf* section) but I see a lot of macros that people use that
> are not on t
On Wed, Jun 5, 2013 at 10:37 PM, Kip Warner wrote:
> My make install target for my autotool'd project's translations
> directory has a number of prerequisites. The one which seems to be
> causing trouble is the install-data-yes target. Yes, I am aware the path
> I am using contains spaces and yes
On Fri, Jun 7, 2013 at 2:55 PM, Darren Garvey wrote:
> Hi all,
>
> I've been trying to make a large automake-generated project I work on build
> quieter. While there is some support for "silent-rules", there are several
> places where automake templates* don't silence themselves, which I'd like
>
> %SILENT% doesn't work in any of the places I tried. I'm speculating that
> this is because it's substituted too early. I see it being used in a few
> places (eg. lib/am/library.am), but those rules are full of other %NAME%
> strings.
Different files will use different substitutions. For SILENT to
openvswitch should tell you what its dependencies are.
On Sat, Sep 28, 2013 at 7:37 PM, Ferenc Cserepkei wrote:
> Welcome,
> I'm doing jenkins build of openvswitch-1.11 on a centos 6.4 amd64 host.
> Openvswitch coming from git repo has a boot.sh scrit contains command
> autoreconf --install --for
> The not so nice part is, though, that the Makefile.am looks quite messy.
> Very messy in fact:
>
>
> $ cat Makefile.am
>
> vortrag = vortrag.pdf
> vortrag_DATA = vortrag.org data.txt dist-tarball.png
> vortragdir = .
>
> EXTRA_DIST = ${vortrag_DATA} ${vortrag}
> MOSTLYCLEA
On Wed, Nov 20, 2013 at 9:33 PM, Jason Gross wrote:
> I have a Makefile.am which includes another file in order to get a list of
> files it should compile (I don't want to require running autoreconf and
> configure whenever you add a file that the makefile already knows how to
> compile). But thi
On Sat, Nov 2, 2013 at 5:43 PM, Denis Laroche wrote:
> I used version 2.69 of autoconf and version 1.13.4 of automake to
> generate the configure script. I use a recent version of GNU make,
> 3.82, on the HP-UX system. I also use option subdir-objects in
> AM_INIT_AUTOMAKE to minimize the number o
On Mon, Dec 16, 2013 at 3:49 PM, Jason Gross wrote:
> These compiled files get distributed/installed, so I think they belong in
> DATA.
>
> The solution I ended up using was manually including an "all-am" target
> below the definition, which overrides the one that automake generates.
>
> I think t
On Fri, Dec 6, 2013 at 8:56 AM, Richard Crozier wrote:
> I am seeing the same issue as described in this previous post to the
> automake mailing list:
>
> http://gnu-automake.7480.n7.nabble.com/quot-error-while-loading-shared-libraries-foo-so-0-cannot-open-shared-object-file-No-such-file-or-di-td3
On Mon, Dec 2, 2013 at 8:21 PM, PenguinDude24 wrote:
> Automake generates the Makefile.in files, and configure makes the 'Makefile'
> for the directory. But the generated makefiles give errors. GNU Make gives
> the ominous 'missing separator error'. That errors can be triggered for a
> variety of
On Sun, Apr 13, 2014 at 2:47 AM, Jonas Thiem wrote:
> # -
> # Unit test section
> # -
> TESTS=
> testd = ctests
> TEST_CFLAGS= $(AM_CFLAGS) -DUNITTEST
>
> # -
> # C tests
> # -
> check_PROGRAMS = $(testd)/test-imgloader $(testd)/test-texman-1
> $(tes
On Tue, Apr 22, 2014 at 5:06 PM, Nick Bowler wrote:
> On 2014-04-22 16:15 +0100, Gavin Smith wrote:
>> Is support for setting variables with names of source directories
>> after automake is run (with configure scripts, or on the command line
>> when make is run) is needed? If
On Wed, Jun 18, 2014 at 3:47 AM, Michael Lueck
wrote:
> Prefix, building the program with non root permissions to be run in the
> context of a user's home directory.
>
> PID file, generally defaults to /var/run, however in this case permissions
> are not granted to /var/run. One could assume ~/var
On Mon, Jul 14, 2014 at 6:49 PM, Will Estes wrote:
> I have the following in my Makefile.am, and automake is not using the rule to
> build the executable.
>
> tableopts_nr%.c: tableopts.l4
> $(FLEX) -P $(subst -,_,$(*F)) $* -o $@ $<
>
> tableopts_nr%.$(OBJEXT): tableopts_nr%.c
> $
On Thu, Jul 24, 2014 at 9:09 PM, David Beer wrote:
> All,
>
> I am currently trying to get our project completely compatible with
> automake 1.14. We have multiple places where we compile a source file from
> another of the project's subdirectories in a given subdirectory. The two
> main use cases
On Thu, Jul 24, 2014 at 4:48 PM, Steffen Dettmer
wrote:
> Hi,
>
> I have a test that generates a log file, which I can manually run via
> "make check". Is there a simple way to automate that? For the moment I
> just created a pragmatic target "autotest", but I think it is ugly
> (and too specific)
On Thu, Jul 31, 2014 at 9:32 PM, David Beer wrote:
> Gavin,
>
> Thanks for your reply. Here's a more specific breakdown of what the project
> does:
>
> src/a/Makefile.am:
>
> a_SOURCES = bob.c tom.c
>
> src/b/Makefile.am:
>
> b_SOURCES = mary.c ../a/tom.c
>
> The purpose was so that tom.c would be
On Sun, Aug 17, 2014 at 6:05 PM, fr33domlover wrote:
> Hello automakers!
>
> I'm using autoconf 2.69 and automake 1.11.6 (Debian 7 stable). Recently I
> tried
> defining the source code folder name using a variable and strange things
> happen.
> I'm not sure whether this is a bug or my mistake.
On Tue, Aug 12, 2014 at 4:10 PM, Wookey wrote:
> As porting work (for arm64) recently I have done a lot of fixing up
> packages to run autoreconf on build as this is the only way to ensure
> that their config.sub/guess and libtool files are up to date for
> architectures released since the softwar
On Wed, Aug 20, 2014 at 12:47 AM, Arthur Schwarz wrote:
> I'm trying to build and distribute a static library and keep getting a "
> warning: 'libslip.a': linking libraries using a non-POSIX archiver requires
> AM_PROG_AR' in 'configure.ac'" message. I don't know why.
>
> The configure.ac lines i
not recognized as occurring in the file as it is expected to. Try
removing the "#" character in front of "AM_PROG_AR" to see if you
still get this error message.
On Wed, Aug 20, 2014 at 1:36 AM, Arthur Schwarz wrote:
> Isn't '#' just a commen
On Wed, Oct 29, 2014 at 10:39 PM, Eric Blake wrote:
> On 10/29/2014 04:29 PM, Diego Elio Pettenò wrote:
>
>> Can't we just say that gnu-flavour automake is pointless and foreign should
>> be the default? Or am I too opinionated on that?
>
> For GNU projects, the 'gnu' flavor still makes sense, eve
On Sun, Nov 2, 2014 at 6:27 PM, Arno Bootsmann wrote:
> I am trying to compile Automake on mac os x 10.6.8, but get the following
> error
> message:
>
> forge:automake-1.14.1 boomaxx$ make
> cd . && "/opt/src/automake-1.14.1/t/wrap/automake-1.14" --gnu --ignore-deps
> Makefile
> Can't locate /op
On Tue, Oct 28, 2014 at 3:34 AM, Wy kevinthesun wrote:
> Finally I tried to test Encoder library as before. I create "Test6" Project
> which only included "Encoder.h" and wrote Makefile.am similarly as Test3:
>
> bin_PROGRAMS = Test6
> Test6_SOURCES = Test6.cpp
>
> Test6_LDFLAGS = -L/home/kevinthe
On 4 March 2015 at 19:05, Andy Falanga (afalanga) wrote:
> I'm trying to reproduce this using the automake tools. I have this in the
> Makefile.am located in sata:
>
> lib_LTLIBRARIES = satacpp.la
> satacpp_la_SOURCES = ...
>
> pyexec_LTLIBRAIRES = sata.la
> sata_la_LDFLAGS = -module
> sata_la_L
On 8 March 2015 at 11:50, Diego Elio Pettenò wrote:
> On 8 March 2015 at 09:46, Harlan Stenn wrote:
>
>> foo_SRCS = ... $(srcdir)/../foo/bar.c
>>
>
> Have you tried omitting $(srcdir) altogether? It should work just fine
> then. So just foo_SOURCES = ../foo/bar.c
This does work, once you manage
On 9 March 2015 at 15:06, Marc Wäckerlin wrote:
> According to the official documentation(*):
> --
> Here is an example of how to define a conditional config file:
> AM_CONDITIONAL([SHELL_WRAPPER], [test "x$with_wrapper" = xtrue])
> AM_COND_IF([SHELL_WRAPPER
On 8 March 2015 at 22:29, Marc Wäckerlin wrote:
> I didn't find any proper solution with google for the following problem:
>
> How do the makefile rules come into the makefile?
>
> E.g. when I use AC_PROG_CXX, in the makefile rules should be added, such as
> compiling .o from .cxx and to cleanup .
On 10 March 2015 at 22:04, Andy Falanga (afalanga) wrote:
> I'm trying to figure out how things like CXXFLAGS and CFLAGS get passed to
> ultimate point of compilation. I thought I had it down but something that
> just happened recently has me wondering. I've gotten my project building now
> u
On 25 April 2015 at 00:04, Arthur Schwarz wrote:
>
> In 15.3.3.1 Command-line arguments for test drivers
>
> --log-file=PATH.log
>
> The .log file the test driver must create (see Basics of test metadata).
> If it has a directory component (as in e.g., sub/foo.log), the test harness
> will ens
On 25 April 2015 at 00:13, Arthur Schwarz wrote:
>
> 15.3.3.1 Command-line arguments for test drivers
>
> --color-tests={yes|no}
>
> Is 'always' an option? See 15.2.1 Scripts-based Testsuites
> "AM_COLOR_TESTS=always"
>From my reading, if AM_COLOR_TESTS=always, then --color-tests=yes will
be pas
On 25 April 2015 at 00:27, Arthur Schwarz wrote:
>
> In "15.3.3.1 Command-line arguments for test drivers" there is the
> statement:
>
> "The first non-option argument passed to the test driver is the program to
> be run, and all the following ones are command-line options and arguments
> for this
On 13 April 2015 at 20:34, Arthur Schwarz wrote:
> I am very much a novice at this so if I have made (some) mistake(s) please
> tell me how to correct them.
>
> I have a suggested change to the general introduction given in Section 15
> "support for test suites" section of the manual. Before I pro
On 25 April 2015 at 13:11, Arthur Schwarz wrote:
>> In "15.3.2 Declaring Custom Test Drivers" we have the automake variables
>> LOG_DRIVER and ext_LOG_DRIVER. Assuming LOG_DRIVER = driver, does the
>> statement mean that to execute "driver" I type:
>>
>>make driver
>>
>> Instead of
>>make
On 2 April 2015 at 17:41, Arthur Schwarz wrote:
> Win7-64-bit
> Cygwin
> Automake 1.14.1
>
> The example given on the page has:
>
> % cat configure.ac
> o o o
> AC_REQUIRE_AUX_FILE([tap-driver.sh])
>
> o o o
>
> % cat Makefile.am
> TEST_LOG_DRIVER = env AM_TAP_AWK='$(AWK)' $(SHELL) \
> $(to
On 28 March 2015 at 23:54, Arthur Schwarz wrote:
> Win7-64 bits
> Cygwin
> Automake 1.14, Nov 2013
>
> 15.2.3 Parallel Test Harness
> Pg. 113
>
> "TEST_EXTENSIONS defaults to .test; it can be overridden by the user ..."
>
> All examples indicate that this is a developer variable, and the body of
On 1 April 2015 at 00:35, Arthur Schwarz wrote:
> Well, I've never done a patch. More appropriately, the Automake document
> needs a thorough review and rewriting. I don't have the knowledge to do
> that, I don't know automake. More appropriately, the patches would be more
> extensive then just ca
On 26 April 2015 at 01:25, Arthur Schwarz wrote:
>
> Well, putting it gently you have a good product and one of (maybe, the)
> worst manual on earth describing it.
I'd like to see improvements as well, but calling other people's work
"the worst manual on earth" is not conducive to soliciting thei
On 26 April 2015 at 16:30, Arthur Schwarz wrote:
>
>
> 15.3.3.1 Command-line arguments for test drivers
>
>--test-name=NAME
>
>The name of the test, with VPATH prefix (if any) removed. This can
> have a suffix and a directory component (as in e.g., sub/foo.test), and is
> mostly meant
On 26 April 2015 at 18:39, Arthur Schwarz wrote:
> Now for the case you mentioned in identifying a program, which is really a
> test case renamed in the manual for mystifying and unknowable reasons. Well,
> there is no mechanism for "The first non-option argument passed to the test
> driver is the
> As a point, 15.3.3.1 Command-line arguments for test drivers shows all
> options as having the syntax "--option=value". Your example does not have
> this syntax. Will your example work? Should this be in the manual, as in
> "--option[=| ]value?"
I am sure that both should be supported although I
On 30 April 2015 at 23:01, Arthur Schwarz wrote:
>
> I'm trying figure out how the serial testing environment works and:
>
> If TESTS is defined in Makefile.am as
> TESTS = a.sh
>
> And the user changes it to:
>
>env TESTS="b.sh c.exe d.py e.pl" make -e check
>
> What happens?
>
Why not tr
On 10 May 2015 at 13:57, Bas Vodde wrote:
> I'm trying to change my projects configure.ac so that it sets the
> COPYFILE_DISABLE=1 environment variable to influence the make dist target.
What running program needs to have this environment variable set in
its environment? Is it the shells that are
On 18 May 2015 at 15:39, Arthur Schwarz wrote:
> I've just tried to create and test my test case and received the message
> below. The script which is used to create the distribution is included along
> with the configure.ac, Makefile.am, and src/Makkefile.am files. The setup is
> for testing and
On 21 May 2015 at 09:12, Roman Neuhauser wrote:
> # aschwarz1...@att.net / 2015-05-20 17:00:57 -0700:
>> 15.2.3 Parallel Test Harness
>> Suppose Makefile looks something like:
>>
>>TESTS = foo.exe
>>
>> Then
>>TEST_LOGS = foo.log
>>
>> And the user sets this to
>>env TEST_LOGS = bar.l
On 27 May 2015 at 22:27, Arthur Schwarz wrote:
> Then is seems that the test harness would have to do:
> cat data | tap-driver.sh
> ./script.sh | tap-driver.sh
>
> Because the awk loop in tap-driver.sh does a getline which reads from an
> input pipe (stdin). Have I read the code and the document c
On 25 May 2015 at 16:28, Arthur Schwarz wrote:
>
> What programs can be used for custom test drivers and test classes?
>
> check_JAVA
> check_LISP
> check_PYTHON
> check_FORTRAN
> check_?
There's no such variable as check_FORTRAN. Each language doesn't have
it's own "primary".
I believe that che
Hello all,
I wonder if anyone could give pointers to advice on how to integrate a
Perl XS module with an Automake build system? Over at the Texinfo
project we're starting to replace parts of makeinfo with loadable
native-code modules, for speed.
The problem is that the Makefiles produced by ExtUt
On 30 June 2015 at 14:25, Bob Friesenhahn wrote:
> In addition to behavior issues, a major problem is that the re-link
> capabilities offered by libtool are not available. If one links from the
> Perl module to a shared library in the build tree, then there is the risk of
> continued reference to
On 30 June 2015 at 22:41, Bob Friesenhahn wrote:
>> as well as a heap of other variable definitions copied from the
>> MakeMaker Makefile. Now I have to see how ExtUtils:MakeMaker knew what
>> flags to use to see if I can replicate it.
>
>
> These definitely come from how Perl was originally compi
On 30 June 2015 at 23:06, Bob Friesenhahn wrote:
> On Tue, 30 Jun 2015, Gavin Smith wrote:
>>
>>
>> What you say about using a different compiler is worrying, though, and
>> I hadn't thought about it before. So basically when compiling an XS
>> module, you
On 2 July 2015 at 18:02, Arthur Schwarz wrote:
> Shows specific identification of compilers, sic. PL_LOG_COMPILER and
> PY_LOG_COMPILER. Automake seems to have knowledge of particular language
> compilers and the user can specify their use as in:
>
> check_JAVA
> check_LISP
> check_PYT
On 30 June 2015 at 23:06, Bob Friesenhahn wrote:
> If you use a system which supports several completely different compilers
> targeting the same ABI, you immediately find dismay unless you compile
> Perl using the same compiler you plan to use.
>
> This is quite evident on Solaris systems which
On 3 July 2015 at 20:31, Russ Allbery wrote:
> You can see the approach that I took in various of my packages, such as:
>
> http://git.eyrie.org/?p=kerberos/webauth.git;a=blob;f=Makefile.am;h=2cc0aba845f450afcd60a6c01e02a33cb9bdc803;hb=9d3555c7f9047f5ac1c67237379072df5b864b82
>
> Search for BINDIN
On 11 July 2015 at 06:38, Harlan Stenn wrote:
> I'm thinking I want to run a hook before the distdir target is run.
>
> What's a good way to do that?
>
> The reason for this is that I'm packaging at least 2 nested packages in
> my distribution. We only want to configure these if we need them. Th
On 24 July 2015 at 20:13, Guillaume Marcais wrote:
> I am improving/writing a C++ project (called MUMmer) which creates a shared
> library with libtool. In the same project, I also create a SWIG binding to
> access in Perl some of the functionality of this shared library.
>
> Libtool creates the s
On 28 July 2015 at 16:58, Guillaume Marcais wrote:
> On Sat, Jul 25, 2015 at 9:41 AM, Gavin Smith
> wrote:
>
>>
>> I'd suggest not hard-coding the name of the shared library in the Perl
>> code. It could be extracted from the *.la file. That would likely
>>
The next release of Texinfo will make a @setfilename line optional in
Texinfo files. Unfortunately Automake depends on its presence (as of
Automake 1.15). Please consider removing this requirement.
On 22 September 2015 at 18:12, Andy Falanga (afalanga)
wrote:
> Hi,
>
> My project has some doc files which are currently generated by the
> parsing engine of Visual Studio. Our plan is to simply generate them,
> periodically, and include them with our Linux build via autotools. I'm
> not sure o
On 22 September 2015 at 18:12, Andy Falanga (afalanga)
wrote:
> My project has some doc files which are currently generated by the
> parsing engine of Visual Studio. Our plan is to simply generate them,
> periodically, and include them with our Linux build via autotools. I'm
> not sure of how to
On 23 September 2015 at 00:14, Andy Falanga (afalanga)
wrote:
>> I previously wrote out a reply and then deleted it when I read your
>> email again. But maybe it was what you wanted. I was going to suggest
>> using a variable based on the DATA "primary", in Automake's
>> terminology. E.g. dist_foo
I've uploaded my work on editing the Automake manual at
https://bitbucket.org/gavin_smith_/buildsystem-manual. It combines
material from both the Autoconf and Automake manuals. I was hoping to
present this material in a logical way that would make sense to a
beginner. As you'll see from the many TO
On 26 September 2015 at 15:36, Gavin Smith wrote:
> I've uploaded my work on editing the Automake manual at
> https://bitbucket.org/gavin_smith_/buildsystem-manual.
For reading on the WWW, I've put it on SourceForge, at
http://buildsystem-manual.sourceforge.net/index.html.
On 12 November 2015 at 19:19, Will Estes wrote:
> and Makefile.am:
>
> check_PROGRAMS = test
>
> test_SOURCES = test.l
> nodist_test_SOURCES = test.c
>
> I had to manually create the m4/ directory, but then:
>
> autoreconf -if && ./configure && make && make dist
>
> produces a tar ball with test.c
On 29 December 2015 at 19:52, Kees-Jan Dijkzeul wrote:
> Either would obviously work, but kind of defeat the purpose of having
> incremental builds, and unnecessarily load the buildserver. A
> solution where I could do an incremental build after a configure
> incantation would be much preferred.
On 29 December 2015 at 21:42, Daniel Campoverde Carrión [Alx741]
wrote:
> Hello everyone,
>
> I'm trying to use autotools for the first time for a simple microntroller
> project, one of my Makefile.am files contains this:
>
>
>>PIC_DEVICE=18f4550
>>CC=sdcc
>>LD=sdcc
>>FLAGS= --use-non-free -mpic16
On 6 January 2016 at 06:01, Thomas Martitz wrote:
> Am 05.01.2016 um 23:41 schrieb Gavin Smith:
>> On 5 January 2016 at 21:05, Thomas Martitz wrote:
>>> Automake source code is a myth to me, I wasn't able to find the code that
>>> implements this limitation (onl
On 6 January 2016 at 09:23, Thomas Martitz wrote:
> This option is intended to be used in conjunction with subdir-objects and
> Automake-time substitutions for included makefile fragments (%C%, %D%). It
> suppresses the generation path components in object filenames.
>
> It should equivalent to se
On 8 January 2016 at 14:33, Gavin Smith wrote:
> Failing that, it would be better for conditional SHORTNAME to work,
> instead of adding a new option.
For example:
--- automake-orig 2016-01-08 14:54:04.0 +
+++ /home/g/local/bin/automake 2016-01-08 15:06:06.0
On 6 January 2016 at 09:17, Thomas Martitz wrote:
> It should equivalent to setting %C%_foo_SHORTNAME=foo, except it can work if
> the makefile fragment is conditionally included, which improves the modularity
> of Automake-using projects.
>
> Example:
> without object-shortname
> root/path/to/M
> configure:
>
> ./configure ... \
>--with-python \
>PYCXX_SRCDIR=/usr/share/python2.7/CXX/Python2
>
>
> Makefile.am:
>
> nodist_libpyroute_la_SOURCES = $(PYCXX_SRCDIR)/cxxextensions.c
> nodist_libpyroute_la_SOURCES += $(PYCXX_SRCDIR)/cxx_extensions.cxx
> nodist_libpyroute_la_SOURCES += $(P
Hello,
In the Autoconf manual we read:
When you use the same text in a macro argument, you must therefore
have an extra quotation level (since one is stripped away by the macro
substitution). In general, then, it is a good idea to use double
quoting for all literal string arguments, either
On 22 December 2016 at 19:00, Eric Blake wrote:
> On 06/12/2016 05:25 AM, Gavin Smith wrote:
>> Hello,
>
> Apologies for just now noticing this thread.
>
>>
>> In the Autoconf manual we read:
>
> Any reason you mailed this to the automake list, and not auto
On Tue, Jun 27, 2017 at 11:14:37AM +0200, Hans Åberg wrote:
> [Please cc me, as I am not on this list.]
>
> When I put 'export PDFTEX = luatex', then it works correctly with ./configure
> && make, but 'make distcheck' still uses pdftex. Why is that?
>
Why shouldn't it?
On 25 February 2018 at 19:13, Jonas Thiem wrote:
> Disclaimer: I haven't read this part of the docs myself. But for what
> it's worth, I think Maude looks a bit like a misspelling of Make and
> doesn't stick out that well, compared to "exampleprog" or something.
> Also, I personally would suggest
On Wed, Mar 13, 2019 at 12:39:24PM +0100, Gregorius van den Hoven wrote:
> I am hoping you find this an interesting development and are willing to
> double check my work and/or forward it to interested parties. If my
> algorithm gains traction it should have a positive impact on mankind's
> carbon
would be needed would be for someone to have a look at this
patch and apply it for the next Automake release.
On 1/25/19, Gavin Smith wrote:
> @setfilename should not be required to occur inside Texinfo files, as it
> makes it harder to get them working.
>
> Earlier on this:
> https:
Thanks for writing all of this.
I'm writing from the perspective of a long-term user of the autotools.
A discussion like the one you have started will likely attract many
opinions. Some will be contradictory. However, somebody in the end
will have to decide.
The challenge seems to be to evolve th
On Thu, Jan 21, 2021 at 11:01:34AM -0500, Zack Weinberg wrote:
> Having said that, switching to *anything else* would be a gigantic
> task -- multiple full-time person-years of effort just for the core --
> and would mean either porting or losing all of the third-party macro
> libraries. I don't t
On Wed, Jun 23, 2021 at 12:27:15PM -0400, Nick Bowler wrote:
> On 2021-06-23, Werner LEMBERG wrote:
> > The file `texinfo.tex` is in the list of files (given by `automake
> > --help`) that gets always distributed. How can I disable this? I
> > don't have texinfo documentation.
>
> The texinfo.t
top installing ABOUT-NLS while it is
an automake requirement.
Hence, please consider this patch to automake to remove ABOUT-NLS as
a requirement.
ABOUT-NLS is still distributed automatically after this change.
commit 7456b0eeb99cbecada41d5dbbd5f5f02d02ce0a1
Author: Gavin Smith
Date: 2024-10
On Sun, Oct 20, 2024 at 03:35:01PM -0600, Karl Berry wrote:
> automake: require ABOUT-NLS only at gnits
>
> Thanks Gavin (and Bruno). I pushed the change to automake. -k
Thank you!
the GNU Coding Standards don't require
> this file). But please keep it mandatory in 'gnits' mode, which is a
> kind of super-picky distribution mode.
Here's an amended version with an amended commit message:
commit 6e176eef4560460426396cf842b31bebe23bddc4 (HEAD -> ma
90 matches
Mail list logo
