Re: Do not require ABOUT-NLS in source directory

Gavin Smith wrote: > Here's an amended version with an amended commit message: Thanks. OK with me. I'll then update the gettext documentation. Bruno

Re: Do not require ABOUT-NLS in source directory

Hi Gavin, Gavin Smith wrote: > The "gettextize" program from gettext installs a file ABOUT-NLS, > ... > Users are unlikely ever to look at this file I disagree. It is in the top-level directory, precisely so that users easily see it. > and it is pointless clutter > in a directory listing. If th

improve display of whether sleep supports fractional seconds

t with the rest. Verified to pass "make check". >From 43841ccedc4c0055d50df64934fc6a673d9f1551 Mon Sep 17 00:00:00 2001 From: Bruno Haible Date: Tue, 2 Jul 2024 00:19:27 +0200 Subject: [PATCH] automake: Improve display of whether sleep supports fractional seconds

improve display of filesystem timestamp resolution

29c58da4fbec47a5e78a63f9673670c;hb=HEAD#l152 >From 9f15a04dd9865db339595b0710a4ebefed6cd853 Mon Sep 17 00:00:00 2001 From: Bruno Haible Date: Mon, 1 Jul 2024 21:04:17 +0200 Subject: [PATCH] automake: Improve display of filesystem timestamp resolution. * m4/sanity.m4 (_AM_FIL

Re: [platform-testers] automake-1.16.92 released

Hi Jim, > > I created a Gnulib testdir (of all of Gnulib) with automake-1.16.92, > > and built that on various platforms (from Alpine Linux to MSVC) [1]. > > Everything OK; all tests passed. > > > > Obviously this tests only a small part of the Automake functionality, > > namely the part of "just

Re: [platform-testers] automake-1.16.92 released

Jim Meyering wrote: > We're particularly interested in bugs or regressions in the actual > Automake functionality. I created a Gnulib testdir (of all of Gnulib) with automake-1.16.92, and built that on various platforms (from Alpine Linux to MSVC) [1]. Everything OK; all tests passed. Obviously t

Re: branch master updated: lib scripts: add "(GNU Automake)" to --version output, etc.

Re : Thanks for having done this, Karl. It fixes the issue you reported to bug-gnulib (regarding 'ar-lib'). But in lib/test-driver: > @@ -50,6 +50,11 @@ Usage: > > The '--test-name', '--log-file' and '--trs-file' option

Re: 1.16.90 regression: configure now takes 7 seconds to start

Zack Weinberg wrote: > Literally as I type this I am > watching gettext 0.22 run its ridiculous number of configure scripts a > second time from inside `make`. I'm glad that you didn't write "its ridiculously large configure scripts" :-) Jokes aside, it's highly unusual that 'configure' runs twic

Re: 1.16.90 regression: configure now takes 7 seconds to start

Jacob Bachmeyer wrote: > under what conditions can "checking that > generated files are newer than configure" actually fail? I mentioned two such conditions in [1]: - Skewed clocks. (I see this regularly on VMs that have 1 or 2 hours of skew.) - If the configure file was created less than

Re: 1.16.90 regression: configure now takes 7 seconds to start

Nick Bowler wrote: > while ${MAKE-make} -f conftest.mk >/dev/null 2>&1 > do > touch config.status > done]) I would use 'echo >> config.status' instead of 'touch config.status'. Rationale: When the user is working in an NFS file system mount, and there is a clock skew between the current

Re: 1.16.90 regression: configure now takes 7 seconds to start

Karl Berry wrote: >This patch is conservative; IMO safe for a 1.17 release. > > I like the idea of a conservative patch, for sure. I see that what > you're doing here is simply omitting the 1 second trial for the sake of > saving that time, in exchange for accepting a 2s delay in the Automake

Re: 1.16.90 regression: configure now takes 7 seconds to start

e they were reported in September 2010. Bruno >From f1e6c0a5c7982a70d9d28798feb64c19cde20122 Mon Sep 17 00:00:00 2001 From: Bruno Haible Date: Mon, 17 Jun 2024 00:13:21 +0200 Subject: [PATCH] automake: Speed up _AM_FILESYSTEM_TIMESTAMP_RESOLUTION execution. * m4/sanity.m4 (_AM_FILESYSTEM_TIMES

Re: 1.16.90 regression: configure now takes 7 seconds to start

Hi Karl, > I understand that equal timestamps are considered up to date Yes, except for old HP-UX 'make', which no one uses any more, all 'make' programs consider equal timestamps as "up-to-date". > Ok, but > then why is configure generating config.status/etc. such a special case > that it requi

Re: 1.16.90 regression: configure now takes 7 seconds to start

g I missed? With this patch, Automake's "make check" passes, except for a test failure in t/instdir-ltlib.sh that Paul introduced a couple of days ago: https://git.savannah.gnu.org/gitweb/?p=automake.git;a=commit;h=1d35638b23e95fe6f41c828a3442f6d7f242f4c4 Bruno >From 5c601af4d9e8e

Re: 1.16.90 regression: configure now takes 7 seconds to start

he 2-seconds delay goes away, as expected. Note: The redirection of AS_MESSAGE_FD may look ugly, but is portable. Gnulib uses this idiom for three years already. Bruno >From 3a7f1cb3ea4a51caf77cf6c06a1d9528764adc2b Mon Sep 17 00:00:00 2001 From: Bruno Haible Date: Thu

Re: 1.16.90 regression: configure now takes 7 seconds to start

Karl Berry wrote: > The simple change is to omit the make test if we are at resolution 1. > That will save 4 seconds. It should save 6 seconds. Because it goes like this: - Test whether 0.01 sec works. - Test whether 0.1 sec works. - If not, set the variable to 2, because that's the worst ca

system info in test-suite.log

Hi, The 1.16.90 NEWS file states: - test-suite.log now contains basic system information, and the console message about bug reporting on failure has a bit more detail. (bug#68746) 1) This system information is the naked output of some OS commands: (uname -a | awk '{$$2=""; p

Re: 1.16.90 regression: configure now takes 7 seconds to start

Hi Jacob, > > AFAIU, the 4x sleep 0.1 are to determine whether > > am_cv_filesystem_timestamp_resolution should be set to 0.1 or to 1. > > OK, so be it. > > > > But the 6x sleep 1 are to determine whether > > am_cv_filesystem_timestamp_resolution should be set to 1 or 2. > > 2 is known to be the c

no easy way to generate a test-suite.log without skipped tests

r by running make check IGNORE_SKIPPED_LOGS=1 or by defining in the Makefile (or Makefile.am): IGNORE_SKIPPED_LOGS = 1 It includes a unit test, documentation updates, and passes "make check". >From e5ed5248fe4fa5fed521e16929694c9d169540b2 Mon Sep 17 00:00:00 2001 From: Bruno Haible Date:

Re: GNU Coding Standards, automake, and the recent xz-utils backdoor

Richard Stallman commented on Jacob Bachmeyer's idea: > > > Another related check that /would/ have caught this attempt would be > > > comparing the aclocal m4 files in a release against their > (meta)upstream > > > sources before building a package. This is something distribution > >

Re: GNU Coding Standards, automake, and the recent xz-utils backdoor

Jacob Bachmeyer wrote: > Another related check that /would/ have caught this attempt would be > comparing the aclocal m4 files in a release against their (meta)upstream > sources before building a package. This is something distribution > maintainers could do without cooperation from upstream.

Re: GNU Coding Standards, automake, and the recent xz-utils backdoor

Eric Gallager wrote: > What about a 3rd one of these prefixes: "novcs", to teach automake > about which files belong in VCS or not? i.e. then you might have a > variable name like: > dist_novcs_DATA = foo bar baz > ...which would indicate that foo, bar, and baz are data files that > ought to be dis

Re: automated release building service

Jacob Bachmeyer wrote: > >> Essentially, this would be an automated release building service: upon > >> request, make a Git checkout, run autogen.sh or equivalent, make dist, > >> and publish or hash the result. The problem is that an attacker who > >> manages to gain commit access to a repositor

Re: libsystemd dependencies

Jacob Bachmeyer wrote: > some of the blame for this needs to fall on the > systemd maintainers and their "katamari" architecture. There is no good > reason for notifications of daemon startup to pull in liblzma, but using > libsystemd for that purpose does exactly that, and ended up getting >

Re: GNU Coding Standards, automake, and the recent xz-utils backdoor

Bob Friesenhahn wrote: > It is not yet clear if the > maintainer intentionally did this, or if the changes were introduced via > a compromise of his computer. I think it is pretty clear by now. [1][2][3] [1] https://boehs.org/node/everything-i-know-about-the-xz-backdoor [2] https://news.ycombin

Re: GNU Coding Standards, automake, and the recent xz-utils backdoor

Eric Gallager wrote: > > * In order to detect that a tarball contains too many files, that is, > > some files that the release manager did not intend to include, > > the best way is to compare the file list of the current tarball > > with the previous version: > > $ diff -r -q p

Re: GNU Coding Standards, automake, and the recent xz-utils backdoor

Eric Gallager wrote: > Recommending the `distcheck` target to a wider variety of users would > help more projects catch mismatches between things a distribution > tarball is supposed to contain, and things that it isn't. While 'make distcheck' detects some of these mismatches, it does not detect t

Re: Automake's file locking

Zack Weinberg wrote: > There is a potential way forward here. The *only* place in all of > Autoconf and Automake where XFile::lock is used, is by autom4te, to > take an exclusive lock on the entire contents of autom4te.cache. > For this, open-file locks are overkill; we could instead use the > bat

Re: [PATCH] config: drop scripts that automake says are not independent

Eric Blake wrote: > * build-aux/elisp-comp: Delete. What about modules/elisp-comp? > * build-aux/ylwrap: Likewise. OK. Many packages (gettext-runtime/intl, parse-datetime, ...) rely directly on bison. Only packages which support old yacc need this wrapper script, and they typically use Automake.

limited install locations for scripts

Hi, The Automake manual, node "Scripts", says: Scripts can be installed in `bindir', `sbindir', `libexecdir', `pkglibexecdir', or `pkgdatadir'. Also http://lists.gnu.org/archive/html/automake/2012-01/msg4.html confirms this. But why is this set of install locations limited? Why c

Re: should an empty "pkgdata_DATA" cause creation of $(pkgdatadir) by "make install"? (was: Re: [PATCH] gnulib-tool: fix imprecise comments)

[Dropping bug-gnulib from CC.] Stefano Lattarini wrote: > So we're in a sort of a tie here: some users think that the current Automake > behaviour is a feature (and I lean toward that position), other ones (with > Ralf among them, apparently) believe it's a bug. Hmmm. The most important question

Re: Could automake-generated Makefiles required GNU make? (was: Re: [gnu-prog-discuss] portability)

Richard Stallman wrote: > one GNU package could drop support for ordinary Make, and see > how users react. If the level of complaint is not too high, then > another GNU package could do this. Once many GNU packages have done > this, we might conclude it is ok for all GNU packages to do so > (perh

Re: autoconf + automake support for MSVC

Peter Rosin wrote: > my MSYS install seems very reliable to me The groff people have made a different experience. See -- In memoriam Sergei Tretyakov

Re: autoconf + automake support for MSVC

Peter Rosin wrote: > From time to time, I'm wondering if reusing *-*-mingw* for cl is the > right decision. I think so, yes. mingw and msvc share the same kernel, the same object file format, and large parts of the C library. But it definitely ought to be documented, because it is very non-obviou

Re: autoconf + automake support for MSVC

Peter Rosin wrote: > The platform name was discussed a few years back on the libtool lists (I > think somewhere in the gigantic thread "[patch #6448] [MSVC 7/7] Add MSVC > Support" from August 2008 approximately) [0], the outcome was that compiling > with cl for the MS C runtimes uses the same trip

Re: autoconf + automake support for MSVC

Peter Rosin wrote: > >> 'compile' makes cl understand the > >> -l and -L options (and a few others). > > > > So, if I understand it right, you *don't* want to assume that $CC > > understands -l and -L options, like the C compiler in POSIX does for > > ages (cf. > >

Re: autoconf + automake support for MSVC

Peter Rosin wrote: > > When configure.ac does not contain then AM_PROG_CC_C_O macro, > > what do you do? Add it manually? ... > > In that case, as stated above, you can just use compile/ar-lib as you'd > use cccl, the macros only trigger the use of the scripts when they are > needed (and the inclu

Re: autoconf + automake support for MSVC

Peter Rosin wrote: > I didn't want to create yet another fork of cccl, and instead fixed > the 'compile' script in Automake to handle the bits that must be > handled by the build tools (and taught libtool to deal with cl > natively). What I didn't do was add all sorts of options to > 'compile' to m

autoconf + automake support for MSVC

Ralf Wildenhues wrote in : > > > Windows+MSVC. I know this is not a gnulib target. > > > > Yes. But it could become a gnulib target if the $CC wrapper script was > > agreed > > upon in GNU. For example, if Automake would distribu

Re: not breaking "make" after m4 macros and source files changed

Hi Ralf, Stefano, > I'll make amend by writing the new testcases, if you can wait some more > time (maybe a couple of days). Thanks. You can take this as input (I have copyright assignment on file with Automake): > - A renamed m4 macro. > Before: m4/foo.m4 defines FOO1, configure.ac depend

Re: not breaking "make" after m4 macros and source files changed

[CCing the automake list] Ralf Wildenhues wrote in : > > It's that it's unreliable. The autotools > > don't cope automatically with .m4 files that have been renamed, > > That is simply not true with Automake 1.11 any more. > > >

Re: configmake module and automake 1.9.6

Hi Eric, > > In Makefile.am add: > > > > localedir = @localedir@ This is probably not needed at all; the AC_SUBST invocation causes this line to be added to every Makefile.in generated from a Makefile.am automatically. > > In configure.ac add: > > > > dnl Installation directories. > > dn

Re: configmake module and automake 1.9.6

Eric Blake wrote: > I just ran into an issue where libvirt failed to compile when autotooled > with automake 1.9.6, because automake failed to define $(localedir) and > therefore gnulib's configmake module did not define LOCALEDIR. Any > suggestions on how to make gnulib guarantee $(localedir) wil

automake po / pot file integration: when to merge the PO files?

Hi, One issue still needs discussion within the planned po / pot file integration [1]: When should the PO files that are distributed be merged with the POT file? The problem --- PO files (translations) are produced by translators and integrated to the project either by a maintainer (who

Re: absolute build directory with spaces

Hi, Jim Meyering wrote on bug-gnulib: > Coreutils tests with an absolute build directory name that contains > a space. Not quoting this directory name caused a failure. > * tests/test-vc-list-files-git.sh: Quote PATH dir name. > ... > --- a/tests/test-vc-list-files-git.sh > +++ b/tests/test-vc-li

Re: RFE: allow for computed version number

Ralf Wildenhues wrote: > > > AM_INIT_VERSION([$$version], [version=`sh $(top_srcdir)/gen-version`]) > > Here's a slightly different idea. The basic unit of granularity in > makefiles is a target, or a file. The problem we're facing is that the > version is clumped together with all other inf

Re: RFE: allow for computed version number

Hello Ralf, The proposed patch was meant as a prototype, not a proposed patch for Automake. Forget about the code, and just note that it can be done with - a new macro through which the user declares how to compute the version, - some modifications in init.m4 and distdir.am. > > - with a lazi

Re: Shared library location

Russell Shaw asked: > What "make" variable can i utilize that has a value > dependent on whether the package is installed or not? If you need this distinction only in the tests, you can use the Makefile.am variable TESTS_ENVIRONMENT to set an environment variable. Like this: In tests/Makefile.am

Re: RFE: allow for computed version number

Ralf Wildenhues wrote: > I have been playing with the idea of having two separate version strings. > ... > smells of the developer working around limitations of the tools, rather > than the tools providing adequate functionality Yes, exactly. This approach of two pieces is useful for the PACKAGE

Re: RFE: allow for computed version number

Joseph S. Myers wrote: > GCC, Binutils, GDB and EGLIBC support configure options --with-pkgversion > and --with-bugurl. --with-pkgversion changes the package name used in > --version output (and in manuals), so you get e.g. > > GNU assembler (GNU Binutils for Ubuntu) 2.19.1 > > rather than >

Re: cross-compiling on 64 to 32-bit Linux

> what the procedure was for cross-compiling 32-bit apps on a 64-bin Linux > system? You need a bi-arch system, that is, one that has the system libraries both in a 64-bit variant and in a 32-bit variant (typically in /lib64 and /lib, respectively). For compiling in 32-bit mode, I use ./conf

Re: makes which break with `silent-rules'

> - The `silent-rules' option enables Linux kernel-style silent build output. >This option requires the widely supported but non-POSIX `make' feature >of recursive variable expansion, We are talking about constructs like this: == Makefile == all : echo $(XY_V) XY_V = $(X

RFE: allow for computed version number

Hi all, It has been mentioned in a discussion [1][2][3] "In the medium to long run, Autoconf should be changed to not depend at autoconf run time upon a volatile version string." and "the goal is that the version string should _not_ appear in config.h, so there should be _no_ configure o

Re: profile-directed optimization

Paolo Bonzini wrote: > > But the compiler does not know that fstrcmp is called millions of time and > > that this piece of code needs to be optimized for speed rather than for > > space. > > If doing profile-directed optimization, it does know. However, it is impractical: I never used profile-di

Re: automake and gettext macros

[Stripping bug-gnulib from the CCs.] Eric Blake wrote: > > I could define > > a macro AM_XGETTEXT_OPTION([option]) that would augment an AC_SUBSTed > > variable which then gets used in po/Makefile, together with the > > XGETTEXT_OPTIONS from po/Makevars. How does that sound? > > Almost sounds oka

"make test" as an alternative to "make check" (was: Re: GNU tar 1.19 on HP-UX)

[Adding automake mailing list, removing tar and gnulib lists from CC]. H.Merijn Brand wrote: > > Please convince the GNU world to add 'make test' as alias for > > 'make check'. Eric Blake answered: > It won't work for coreutils, where test is the name of a built program. > That's why the GNU Codi

Re: compilation rules with dependencies don't work with subdir-objects

Ralf Wildenhues wrote: > This is currently simply not supported by Automake. Huh? The automake documentation, section "Building a library", says: Extra objects can be added to a library using the `LIBRARY_LIBADD' variable. > Object file names are an internal detail of Automake I understan

Re: [bug-gnulib] race condition gnulib-tool's mostlyclean-local rule

-08-04 Bruno Haible <[EMAIL PROTECTED]> * gnulib-tool (func_emit_lib_Makefile_am, func_emit_tests_Makefile_am): Make the mostlyclean-local rule depend on mostlyclean-generic. Reported by Jim Meyering. Solution suggested by Ralf Wildenhues. *** gnulib-tool 31 Jul 2006 11

Re: proposal for fdl module

Eric Blake writes: > > You had the earlier proposal of making automake be smart enough to install > > the latest upstream version of docs, rather than the version that was > > current when automake was released (but most likely out of date at the > > time that automake is used on a package). If t

Re: proposal for fdl module

Eric Blake wrote: > >>* gnulib-tool: Avoid space-tab. > ... > emacs whitespace mode converts them to plain > tab. Using tab-space instead makes it obvious that both characters were > intended, without having to fight editors trying to collapse them. Thanks for explaining. Bruno

moving po/Makefile.in.in to automake

Hi Alexandre et al., In November/December 2003, we started thinking about how to extend automake so that po/Makefile.in.in can be replaced with a po/Makefile.am or entirely integrated into the main Makefile.am. On 2003-11-11 I explained the details of existing PO file support. http://lists.gnu.

moving $(mkdir_p) from automake to autoconf

directories needs this functionality. The install-sh is already in the autoconf package, and AC_PROG_INSTALL requires it. Therefore I propose to move the AM_PROG_MKDIR_P that defines an @mkdir_p@ variable to autoconf. The sooner, the better. Find attached a raw sketch. 2006-04-17 Bruno Haible

RFE: option to avoid autoreconf recursion

Hi, For gnulib-tool, it would be useful if 'autoreconf' had an option --no-recurse or --no-recursion or --no-recursive that would avoid recursive self-invocations of autoreconf. The use case is: gnulib-tool creates many directories with each a Makefile.am and configure.ac and configure file, an

Re: ax_prog_csc / Re: C# support for automake

Guido Draheim wrote: > create a .NET wrappers for the linux dvb kernel api. It does > work - getting libtool to compile a native shared library > being called from a managed dll that imports symbols from it. Which are the command lines that you use for doing this? I'd like to understand which tool

Re: C# support for automake

Ralf Wildenhues wrote: > > Yes. I think only the strong names of dependencies are hardcoded into > > .dlls and .exes, not the paths where to find them. > > So people rely on installed paths being default-findable by the engine? Yes. People install all libraries into $prefix/lib. > Hmm. This soun

Re: C# support for automake

Ralf Wildenhues wrote: > > So, every object code library and every executable is assigned a > > so-called "strong name". The strong names of the dependencies are stored > > by the linker inside every library or executable. > > Interesting. Is there an API/command line tool to extract this version?

Re: C# support for automake

Hi Ralf, > > Object code libraries are files with suffix ".dll". They are installed > > under $prefix/lib. > > Is it reasonable to assume that programs will link against these > libraries, which are > - not built in the same package as the dll Yes. Making code available for use by other programs

Re: C# support for automake

Simon Josefsson wrote: > It may be useful to discuss DLL naming. I noted that gettext call the > generated DLL 'GNU.Gettext.dll'. Should we encourage a 'GNU.' > prefix? Should we encourage mixed upper/lower case? This is unrelated to automake. Let's discuss it elsewhere. > > - Target "clean"

C# support for automake

ATH_VAR) AC_SUBST(CLIX_PATH) AC_SUBST(HAVE_ILRUN) AC_SUBST(HAVE_MONO) AC_SUBST(HAVE_CLIX) ]) AC_DEFUN([AM_CSHARPEXEC], [ AM_CSHARPEXEC_OPTIONAL([$1],[$2]) if test -z "$HAVE_CSHARPEXEC"; then AC_FATAL([No C# execution engine found.]) fi ]) ==

Re: error: possibly undefined macro: AC_CHECK_HEADERS_ONCE

Stepan Kasal wrote: > The macro gl_INCLUDED_REGEX contains this: > > m4_syscmd([test -f '$1']) > ifelse(m4_sysval, 0, > [ ... > gl_PREREQ_REGEX > ]) > ... > > Why is the above trick necessary? Why should the macro expansion > depend on the presence of the file? That

Re: libtool 2.1a failed mdemo-make.test on Solaris

kes this rule unnecessary. (Historically, the rule predates the use of BUILT_SOURCES.) Thanks for the hint. I propose this patch in gnulib. Bruno 2005-07-22 Bruno Haible <[EMAIL PROTECTED]> * modules/alloca-opt (Makefile.am): Remove explicit dependency on $(ALLOCA_H),

Re: [bug-gnulib] Re: libtool 2.1a failed mdemo-make.test on Solaris

Ralf Wildenhues wrote: > It's a bit tricky to reproduce: You > need a system which has no argz.h, then configure, then `make check' > without prior make. If you had ever run `make' before in this build > tree, even after `make clean' the dependency information is stored in > libltdl/.deps/*.Plo, a

Re: How to extend automake?

Tom Howard wrote: > The best way I've found to do this sort of think, is to create an > autoconf macro that generates a Makefile fragment and use AC_SUBST_FILE > on that. Awesome! Terrific! Many many thanks for the hint. Harald Dunkel wrote: > It would be pretty cool if Automake could append this

How to extend automake?

Hi, How can I extend automake (other than submitting a patch and waiting for automake-1.10 to be released)? More precisely, when a recipe for a certain feature contains the following instructions: 1. In the top-level directory of your package, create a subdirectory called `bison-po'. It

future of AC_PREREQ

Hi, The automake manual states: "any call to `AC_PREREQ' should be done inside the defined macro, not at the beginning of the file." "a future implementation of `aclocal' (*note Future of aclocal::) will have to temporary include all these third party `.m4' files, maybe several

Re: 1.8 and mkdir_p

Harlan Stenn wrote: > > Well, you can create and maintain a 'config.linuxdistro' on your own... > > Yes, and then code: > > ... > cvo=`config.guess` > case $cvo in > *-*-linux-gnu) > cvo=`config.linuxdistro` > ;; > esac > ... Yes. This is how it's meant. > everywhere one would othe

Re: 1.8 and mkdir_p

Bob Friesenhahn wrote: > One handy use when building for multiple architectures is to use > config.guess to supply part of the build directory name so that it is > very easy to manage heterogeneous builds within one file system. Agreed. That's a use of the distribution name and version that won't

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

f the GNU dnl General Public License. As a special exception to the GNU General dnl Public License, this file may be distributed as part of a program dnl that contains a configuration script generated by Autoconf, under dnl the same distribution terms as the rest of that program. # Test for the GNU C

Re: 1.8 and mkdir_p

Harlan Stenn wrote: > > The differences between ALL of the various linux-gnu implementations are > > so slight that they are far more suited to feature tests than something > > like this. > > Are you really serious? ... > > - RC files? > - packaging mechanism? > - automount filesystem selection bas

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

Harlan Stenn wrote (meaning "Linux distribution" when he writes "OS"): > help tool maintainers make choices > about how things that are hard to find out otherwise (like OS-based > choices). > ... > everybody who wants to make OS-level decisions has to code their own tests > to figure out the OS nam

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

Harlan Stenn wrote in a footnote: > There are people who think a config.guess output that says: > > i686-pc-linux-gnu > > is "normal", while some of us feel that is a particularly useless value and > would prefer to see something like: > > i686-pc-redhat7.3 > > instead, just like the original doc

Re: moving po/Makefile.in.in to automake

Denis Barbier wrote on 2003-11-12: > > The 8-year old way of distributing a PO file directory has several drawbacks: > > - requires separate files (POTFILES.in, Makevars) for customization, > > I can hardly see why this is a drawback. You added support for a > separate po/LINGUAS file in 0.11, an

Re: automake and i18n

Akim Demaille wrote: > But I hear your point, I just beg to differ on the relative > importance. I tend to agree. It's more important to make automake support po/ directories in an easier way _in_general_ (and get rid of gettextize). A proposal in this direction is at http://mail.gnu.org/archive/h

Re: automake 1.7d feedback

Alexandre Duret-Lutz wrote: > 3) automake is not yet able to distinguish rule with commands from > rule without commands (no kidding) ok, then I understand why it can't be fixed before automake-1.8... Thanks for adding the warning in the NEWS file and in the documentation. > 2) this behavi

automake 1.7d feedback

Hi Alexandre et al., automake-1.7d is fine for me: I cannot find anything wrong with it. However, there is an important change in behaviour that IMO should be mentioned in the NEWS file (or maybe even undone): While it was possible to add dependencies to automake targets in automake-1.7.x, such d

RFC: better integration with help2man

Hi Alexandre et al., automake supports the installation manual pages. Man pages for programs are nowadays frequently generated through GNU help2man, documenting the command line options but leaving the rest to the doc in texinfo format. Here's a suggestion for rules that would support this. Assum

RFC: distributing man pages in HTML format

Hi Alexandre et al., automake has acknowledged the importance of the HTML format for documentation through addition of the 'html' target. groff 1.17 can now produce quite good HTML from manual pages in mandoc format. Here's a suggestion for rules that would support this. Assuming Makefile.am cont

moving po/Makefile.in.in to automake

Hi Alexandre et al., The 8-year old way of distributing a PO file directory has several drawbacks: - requires separate files (POTFILES.in, Makevars) for customization, - the rules are not extensible, which hampers the development of new rules for dialect or fancy PO files (like de_AT or [E

Re: results with automake-1.6d

Alexandre Duret-Lutz writes: > Art> gettext (GNU gettext) 0.11.5 > [...] > Art> + /usr/bin/perl /home/arth/gnu/automake/objdir/tests/testSubDir/../../aclocal >-I /home/arth/gnu/automake/objdir/tests/testSubDir/../../m4 >--acdir=/home/arth/gnu/automake/tests/../m4 -I /home/arth/gnu/automake/te

Re: 0.11.5: gettextize with external

Akim Demaille writes: > | > Running gettextize on a project that is not including intl/ still > | > copies and installs m4 files that are not needed. > | > | It is correct. If gettextize did not copy these files, the subsequent > | 'aclocal' invocation would fail. I consider this a bug in the >

Re: AM_GNU_GETTEXT([external]) broken

Charles Wilson writes: > I only added the intl/ directory because there is an overzealous check > in automake itself: You could add a dummy intl directory with only a Makefile.in that does nothing. Bruno

Re: AM_GNU_GETTEXT([external]) broken

Charles Wilson wrote: > gettext.m4 doesn't set BUILD_INCLUDED_GETTEXT or > USE_INCLUDED_GETTEXT (to 'no') when 'external' is specified; the > variables are left unspec'ed. **probably** not a problem -- unless > you gettextize in order to work around the automake bug, like I did > -- in which cas