automake  

Messages by Thread

• Re: State and plans for C++20 module support? Zack Weinberg
  • Re: State and plans for C++20 module support? Paul Eggert
  • Re: State and plans for C++20 module support? Paul Smith
• version numbers and new features Karl Berry
  • Re: version numbers and new features Jim Meyering
  • Re: version numbers and new features Jan Engelhardt
  • Re: version numbers and new features Andrew W. Nosenko
• automake-1.17 fails with latest Perl (5.41.8) - Possible precedence problem between ! and numeric eq (==) Igor Todorovski
  • Re: automake-1.17 fails with latest Perl (5.41.8) - Possible precedence problem between ! and numeric eq (==) Igor Todorovski
  • Re: automake-1.17 fails with latest Perl (5.41.8) - Possible precedence problem between ! and numeric eq (==) Collin Funk
  • RE: automake-1.17 fails with latest Perl (5.41.8) - Possible precedence problem between ! and numeric eq (==) Igor Todorovski
  • RE: automake-1.17 fails with latest Perl (5.41.8) - Possible precedence problem between ! and numeric eq (==) Karl Berry
  • Re: automake-1.17 fails with latest Perl (5.41.8) - Possible precedence problem between ! and numeric eq (==) Jacob Bachmeyer
  • Re: automake-1.17 fails with latest Perl (5.41.8) - Possible precedence problem between ! and numeric eq (==) Karl Berry
  • Re: automake-1.17 fails with latest Perl (5.41.8) - Possible precedence problem between ! and numeric eq (==) Zack Weinberg
  • Re: automake-1.17 fails with latest Perl (5.41.8) - Possible precedence problem between ! and numeric eq (==) Jacob Bachmeyer
  • Re: automake-1.17 fails with latest Perl (5.41.8) - Possible precedence problem between ! and numeric eq (==) Karl Berry
  • Re: automake-1.17 fails with latest Perl (5.41.8) - Possible precedence problem between ! and numeric eq (==) Jacob Bachmeyer
  • Re: automake-1.17 fails with latest Perl (5.41.8) - Possible precedence problem between ! and numeric eq (==) Karl Berry
  • Re: automake-1.17 fails with latest Perl (5.41.8) - Possible precedence problem between ! and numeric eq (==) Jacob Bachmeyer
  • Re: automake-1.17 fails with latest Perl (5.41.8) - Possible precedence problem between ! and numeric eq (==) Karl Berry
  • Re: automake-1.17 fails with latest Perl (5.41.8) - Possible precedence problem between ! and numeric eq (==) Jacob Bachmeyer
  • Re: automake-1.17 fails with latest Perl (5.41.8) - Possible precedence problem between ! and numeric eq (==) Karl Berry
  • Re: automake-1.17 fails with latest Perl (5.41.8) - Possible precedence problem between ! and numeric eq (==) Jacob Bachmeyer
  • Re: automake-1.17 fails with latest Perl (5.41.8) - Possible precedence problem between ! and numeric eq (==) Karl Berry
  • Re: automake-1.17 fails with latest Perl (5.41.8) - Possible precedence problem between ! and numeric eq (==) Jacob Bachmeyer
• Re: Best practise for aclocal paths in cross builds Nick Bowler
  • Re: Best practise for aclocal paths in cross builds Ross Burton
  • aclocal's past and future home (was Re: Best practise for aclocal paths in cross builds) Zack Weinberg
  • Re: aclocal's past and future home (was Re: Best practise for aclocal paths in cross builds) Ross Burton
• "make dist" bug with "EXTRA_DIST += dirname" and built-in rule for "dirname.c" R. Diez
  • Re: "make dist" bug with "EXTRA_DIST += dirname" and built-in rule for "dirname.c" Karl Berry
  • Re: "make dist" bug with "EXTRA_DIST += dirname" and built-in rule for "dirname.c" Karl Berry
  • Re: "make dist" bug with "EXTRA_DIST += dirname" and built-in rule for "dirname.c" R. Diez
  • Re: "make dist" bug with "EXTRA_DIST += dirname" and built-in rule for "dirname.c" Karl Berry
• Do not require ABOUT-NLS in source directory Gavin Smith
  • Re: Do not require ABOUT-NLS in source directory Bruno Haible via Discussion list for automake
  • Re: Do not require ABOUT-NLS in source directory Gavin Smith
  • Re: Do not require ABOUT-NLS in source directory Bruno Haible via Discussion list for automake
  • Re: Do not require ABOUT-NLS in source directory Karl Berry
  • Re: Do not require ABOUT-NLS in source directory Gavin Smith
• libtool wrapper and haskell executable PICCA Frederic-Emmanuel
• "make dist" and conditional build of autotool-enabled subpackage. suzuki toshiya
  • Re: "make dist" and conditional build of autotool-enabled subpackage. Zack Weinberg
  • Re: "make dist" and conditional build of autotool-enabled subpackage. suzuki toshiya
• \# within quotes Tijl Coosemans
  • Re: \# within quotes Zack Weinberg
  • Re: \# within quotes Jan Engelhardt
  • Re: \# within quotes Zack Weinberg
  • Re: \# within quotes Zack Weinberg
  • Re: \# within quotes Nick Bowler
• automake-1.17 released [stable] Jim Meyering
• Possible typo in config.sub Shiro Kawai
  • Re: Possible typo in config.sub Zack Weinberg
  • Re: Possible typo in config.sub Shiro Kawai
• improve display of whether sleep supports fractional seconds Bruno Haible
  • Re: improve display of whether sleep supports fractional seconds Karl Berry
• improve display of filesystem timestamp resolution Bruno Haible
  • Re: improve display of filesystem timestamp resolution Karl Berry
• Fwd: Automake 1.16.90 regression mistakenly "not using Libtool" Dave Hart
• RFC: Add public macros AC_LOG_CMD and AC_LOG_FILE. Zack Weinberg
  • Re: RFC: Add public macros AC_LOG_CMD and AC_LOG_FILE. Nick Bowler
  • Re: RFC: Add public macros AC_LOG_CMD and AC_LOG_FILE. Zack Weinberg
  • Re: RFC: Add public macros AC_LOG_CMD and AC_LOG_FILE. Nick Bowler
  • Re: RFC: Add public macros AC_LOG_CMD and AC_LOG_FILE. Karl Berry
  • Re: RFC: Add public macros AC_LOG_CMD and AC_LOG_FILE. Zack Weinberg
• automake-1.16.92 released Jim Meyering
  • Re: [platform-testers] automake-1.16.92 released Bruno Haible
  • Re: [platform-testers] automake-1.16.92 released Jim Meyering
  • Re: [platform-testers] automake-1.16.92 released Bruno Haible
  • Re: [platform-testers] automake-1.16.92 released Frederic Berat
  • Re: [platform-testers] automake-1.16.92 released Karl Berry
  • Re: [platform-testers] automake-1.16.92 released Karl Berry
  • Re: [platform-testers] automake-1.16.92 released Frederic Berat
  • Re: [platform-testers] automake-1.16.92 released Zack Weinberg
  • Re: [platform-testers] automake-1.16.92 released Nick Bowler
  • Re: automake-1.16.92 released Dave Hart
  • Re: automake-1.16.92 released Karl Berry
  • Re: automake-1.16.92 released Dave Hart
  • Re: automake-1.16.92 released Nick Bowler
  • Re: automake-1.16.92 released Dave Hart
  • Re: bug#71487: automake-1.16.92 released Stefan Kangas
• Re: branch master updated: lib scripts: add "(GNU Automake)" to --version output, etc. Bruno Haible
  • Re: branch master updated: lib scripts: add "(GNU Automake)" to --version output, etc. Karl Berry
• End of life dates vs regression test matrix Dan Kegel
  • Re: End of life dates vs regression test matrix Jacob Bachmeyer
  • Re: End of life dates vs regression test matrix Bob Friesenhahn
  • Re: End of life dates vs regression test matrix Dan Kegel
  • Re: End of life dates vs regression test matrix Nick Bowler
• system info in test-suite.log Bruno Haible
• Re: 1.16.90 regression: configure now takes 7 seconds to start Jacob Bachmeyer
  • Re: 1.16.90 regression: configure now takes 7 seconds to start Bruno Haible
  • Re: 1.16.90 regression: configure now takes 7 seconds to start Simon Richter
  • Re: 1.16.90 regression: configure now takes 7 seconds to start Jacob Bachmeyer
  • Re: 1.16.90 regression: configure now takes 7 seconds to start Karl Berry
  • Re: 1.16.90 regression: configure now takes 7 seconds to start Bruno Haible
  • Re: 1.16.90 regression: configure now takes 7 seconds to start Karl Berry
  • Re: 1.16.90 regression: configure now takes 7 seconds to start Jacob Bachmeyer
  • Re: 1.16.90 regression: configure now takes 7 seconds to start dherring
  • Re: 1.16.90 regression: configure now takes 7 seconds to start Jacob Bachmeyer
  • Re: 1.16.90 regression: configure now takes 7 seconds to start Simon Richter
  • Re: 1.16.90 regression: configure now takes 7 seconds to start Karl Berry
  • Re: improved timestamp resolution test (was: 1.16.90 regression: configure now takes 7 seconds to start) Jacob Bachmeyer
  • Re: improved timestamp resolution test (was: 1.16.90 regression: configure now takes 7 seconds to start) Karl Berry
  • Re: use of make in AM_SANITY_CHECK (was: improved timestamp resolution test) Jacob Bachmeyer
  • Re: use of make in AM_SANITY_CHECK (was: improved timestamp resolution test) Karl Berry
  • Re: use of make in AM_SANITY_CHECK Jacob Bachmeyer
  • Re: 1.16.90 regression: configure now takes 7 seconds to start Simon Richter
  • Re: 1.16.90 regression: configure now takes 7 seconds to start Karl Berry
  • Re: 1.16.90 regression: configure now takes 7 seconds to start Nick Bowler
  • Re: 1.16.90 regression: configure now takes 7 seconds to start Karl Berry
  • Re: 1.16.90 regression: configure now takes 7 seconds to start Zack Weinberg
  • Re: 1.16.90 regression: configure now takes 7 seconds to start Bruno Haible
  • Re: 1.16.90 regression: configure now takes 7 seconds to start Karl Berry
  • Re: 1.16.90 regression: configure now takes 7 seconds to start Bruno Haible
  • Re: 1.16.90 regression: configure now takes 7 seconds to start Karl Berry
  • Re: 1.16.90 regression: configure now takes 7 seconds to start Bruno Haible
  • Re: 1.16.90 regression: configure now takes 7 seconds to start Karl Berry
  • Re: 1.16.90 regression: configure now takes 7 seconds to start Bruno Haible
  • Re: 1.16.90 regression: configure now takes 7 seconds to start Jacob Bachmeyer
  • Re: 1.16.90 regression: configure now takes 7 seconds to start Nick Bowler
  • Re: 1.16.90 regression: configure now takes 7 seconds to start Karl Berry
  • Re: 1.16.90 regression: configure now takes 7 seconds to start Bruno Haible
  • Re: 1.16.90 regression: configure now takes 7 seconds to start Jacob Bachmeyer
  • Re: 1.16.90 regression: configure now takes 7 seconds to start Zack Weinberg
  • Re: 1.16.90 regression: configure now takes 7 seconds to start Jacob Bachmeyer
  • Re: 1.16.90 regression: configure now takes 7 seconds to start Bruno Haible
  • Re: 1.16.90 regression: configure now takes 7 seconds to start Jacob Bachmeyer
  • Re: 1.16.90 regression: configure now takes 7 seconds to start Zack Weinberg
  • Re: 1.16.90 regression: configure now takes 7 seconds to start Bruno Haible
  • Re: 1.16.90 regression: configure now takes 7 seconds to start Zack Weinberg
  • Re: 1.16.90 regression: configure now takes 7 seconds to start Jacob Bachmeyer
  • Re: 1.16.90 regression: configure now takes 7 seconds to start Karl Berry
  • Re: 1.16.90 regression: configure now takes 7 seconds to start Bruno Haible
  • Re: 1.16.90 regression: configure now takes 7 seconds to start Karl Berry
• no easy way to generate a test-suite.log without skipped tests Bruno Haible
• automake-1.16.90 released Jim Meyering
• small patch to make a test work with upcoming autoconf Jim Meyering
  • Re: small patch to make a test work with upcoming autoconf Jim Meyering
• automake 1.17 release plan? Christoph Grüninger
  • Re: automake 1.17 release plan? Karl Berry
  • Re: automake 1.17 release plan? Christoph Grüninger
  • Re: automake 1.17 release plan? Will Estes
  • Bug Resilience Program of German Sovereign Tech Fund Christoph Grüninger
  • Re: Bug Resilience Program of German Sovereign Tech Fund Dan Kegel
  • Re: Bug Resilience Program of German Sovereign Tech Fund Zack Weinberg
  • Re: Bug Resilience Program of German Sovereign Tech Fund Paul Eggert
  • Re: Bug Resilience Program of German Sovereign Tech Fund Christoph Grüninger
  • Re: Bug Resilience Program of German Sovereign Tech Fund Paul Eggert
  • Re: Bug Resilience Program of German Sovereign Tech Fund Christoph Grüninger
  • Re: Bug Resilience Program of German Sovereign Tech Fund Paul Eggert
  • Re: Bug Resilience Program of German Sovereign Tech Fund Christoph Grüninger
  • First draft of application to Sovereign Tech Fund Christoph Grüninger
  • Re: First draft of application to Sovereign Tech Fund Karl Berry
  • Re: First draft of application to Sovereign Tech Fund Christoph Grüninger
  • Re: First draft of application to Sovereign Tech Fund Karl Berry
  • Re: First draft of application to Sovereign Tech Fund Christoph Grüninger
  • Re: First draft of application to Sovereign Tech Fund Karl Berry
  • Re: First draft of application to Sovereign Tech Fund Detlef Riekenberg
  • Re: First draft of application to Sovereign Tech Fund Zack Weinberg
  • Re: First draft of application to Sovereign Tech Fund Karl Berry
  • Re: Bug Resilience Program of German Sovereign Tech Fund Christoph Grüninger
  • Re: Bug Resilience Program of German Sovereign Tech Fund Karl Berry
  • Re: Bug Resilience Program of German Sovereign Tech Fund Christoph Grüninger
  • Re: Bug Resilience Program of German Sovereign Tech Fund Karl Berry
  • Re: Bug Resilience Program of German Sovereign Tech Fund Christoph Grüninger
  • Re: Bug Resilience Program of German Sovereign Tech Fund Karl Berry
  • Re: Bug Resilience Program of German Sovereign Tech Fund Karl Berry
  • Re: Bug Resilience Program of German Sovereign Tech Fund Christoph Grüninger
  • Re: Bug Resilience Program of German Sovereign Tech Fund Jacob Bachmeyer
  • Re: Bug Resilience Program of German Sovereign Tech Fund Christoph Grüninger
  • Re: Bug Resilience Program of German Sovereign Tech Fund Karl Berry
• How to force libtool to use CXX mode? Bob Friesenhahn
  • Re: How to force libtool to use CXX mode? Karl Berry
  • Re: How to force libtool to use CXX mode? Bob Friesenhahn
  • Re: How to force libtool to use CXX mode? Karl Berry
• GNU Coding Standards, automake, and the recent xz-utils backdoor Eric Gallager
  • Re: GNU Coding Standards, automake, and the recent xz-utils backdoor Karl Berry
  • Re: GNU Coding Standards, automake, and the recent xz-utils backdoor Richard Stallman
  • Re: GNU Coding Standards, automake, and the recent xz-utils backdoor Jacob Bachmeyer
  • Re: GNU Coding Standards, automake, and the recent xz-utils backdoor Richard Stallman
  • Re: GCC reporting piped input as a security feature (was: GNU Coding Standards, automake, and the recent xz-utils backdoor) Jacob Bachmeyer
  • Re: GCC reporting piped input as a security feature (was: GNU Coding Standards, automake, and the recent xz-utils backdoor) Richard Stallman
  • Re: GCC reporting piped input as a security feature (was: GNU Coding Standards, automake, and the recent xz-utils backdoor) Richard Stallman
  • Re: GCC reporting piped input as a security feature Jacob Bachmeyer
  • Re: GCC reporting piped input as a security feature Jan Engelhardt
  • Re: GCC reporting piped input as a security feature Jacob Bachmeyer
  • Re: GCC reporting piped input as a security feature Zack Weinberg
  • Re: GCC reporting piped input as a security feature Jacob Bachmeyer
  • Re: GCC reporting piped input as a security feature Alan D. Salewski
  • Re: GCC reporting piped input as a security feature Jacob Bachmeyer
  • Re: GNU Coding Standards, automake, and the recent xz-utils backdoor Bruno Haible
  • Re: GNU Coding Standards, automake, and the recent xz-utils backdoor Eric Gallager
  • Re: GNU Coding Standards, automake, and the recent xz-utils backdoor Bruno Haible
  • Re: GNU Coding Standards, automake, and the recent xz-utils backdoor dherring
  • Re: GNU Coding Standards, automake, and the recent xz-utils backdoor Jacob Bachmeyer
  • Re: GNU Coding Standards, automake, and the recent xz-utils backdoor Jose E. Marchesi
  • Re: GNU Coding Standards, automake, and the recent xz-utils backdoor Jacob Bachmeyer
  • Re: GNU Coding Standards, automake, and the recent xz-utils backdoor Jose E. Marchesi
  • Re: GNU Coding Standards, automake, and the recent xz-utils backdoor Jacob Bachmeyer

• Earlier messages