Re: make check failures

Den 2011-05-24 07:43 skrev Graham Reitz: > After a successful build, make check yields: > > = > 628 of 650 tests failed > (79 tests were not run) > See tests/test-suite.log > Please report to bug-autom...@gnu.org > = > make[3]

Re: autoconf + automake support for MSVC

Den 2011-09-02 23:11 skrev Bruno Haible: > 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 G

Re: autoconf + automake support for MSVC

Den 2011-09-03 00:43 skrev Michael Goffioul: > On Fri, Sep 2, 2011 at 11:26 PM, Peter Rosin wrote: >> The web has a couple of different forked versions of cccl. What is >> the "upstream" for that script? There is ancient support for some >> version of cccl in libto

Re: autoconf + automake support for MSVC

Den 2011-09-03 03:47 skrev Bruno Haible: > 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 wi

Re: autoconf + automake support for MSVC

Hi Stefano, Den 2011-09-03 09:41 skrev Stefano Lattarini: > On Saturday 03 September 2011, Peter Rosin wrote: >> >> [BIG SNIP] >> >> I don't think cccl is the future, I see it as the past. It's >> simply not needed when the needed bits are already in &#x

Re: autoconf + automake support for MSVC

Den 2011-09-03 09:41 skrev Stefano Lattarini: > Oh, also, before doing that, could you please merge the 'maint' > branch into the 'msvc' branch? Or I can do that for you if you > prefer (but then you'll have to double-check that the merge has > been really successfull). I have now merged maint int

Re: autoconf + automake support for MSVC

Den 2011-09-09 19:00 skrev Bruno Haible: > 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

Re: autoconf + automake support for MSVC

Den 2011-09-09 19:27 skrev Bruno Haible: > But since not all packages use the AM_PROG_CC_C_O macro (only the use of > source files in directories without a Makefile.in requires it), I would > better recommend to everyone to use CC="/path/to/compile cl -nologo" > from the beginning. But don't forge

Re: autoconf + automake support for MSVC

Den 2011-09-10 02:22 skrev Bruno Haible: > 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],

Re: autoconf + automake support for MSVC

Den 2011-09-11 00:04 skrev Bruno Haible: > Peter Rosin wrote: >> The main benefits that I see are that you don't have to >> cross compile if you are in MSYS > > You have the wrong notion of "cross compile", if you think cross-compiling > means that $host !=

Re: autoconf + automake support for MSVC

Stefano Lattarini skrev 2011-09-03 09:41: > For what concerns this: are you willing to re-submit your patch > series about AM_PROG_AR to automake-patches? I will try hard to > look into it, if you are willing to do the required testing and > to patiently explain to me the details I won't undertand

Re: autoconf + automake support for MSVC

Stefano Lattarini skrev 2011-10-19 15:59: > On Wednesday 19 October 2011, Peter Rosin wrote: >> Stefano Lattarini skrev 2011-09-03 09:41: >>> For what concerns this: are you willing to re-submit your patch >>> series about AM_PROG_AR to automake-patches? I will try hard

Re: autoconf + automake support for MSVC

Peter Rosin skrev 2011-10-19 18:03: > Stefano Lattarini skrev 2011-10-19 15:59: >> On Wednesday 19 October 2011, Peter Rosin wrote: >>> Stefano Lattarini skrev 2011-09-03 09:41: >>>> For what concerns this: are you willing to re-submit your patch >>>> seri

Manual merges.

g these lines: > Merge branch 'maint' into msvc > > * tests/foo.test: Adjust to new portability requirements due > to the new AM_PROG_AR macro. > * tests/bar.test: Likewise. And this in ChangeLog: > 4711-17-42 Peter Rosin > > Merge branch 'maint&

Re: Manual merges.

Hi Stefano, Stefano Lattarini skrev 2011-10-21 10:17: > On Friday 21 October 2011, Peter Rosin wrote: >> Hi! >> > Hi Peter. > >> I checked to see what would happen if I merged maint back into msvc after >> commiting the AM_PROG_AR series, and there is some mino

Re: [RFC] Releasing automake 1.11.2

Stefano Lattarini skrev 2011-10-16 17:44: > Hello automakers. > > I think it's about time to release automake 1.11.2 -- the `maint' > branch contains various bug fixes w.r.t. the 1.11.1 release (some > of them quite important), and offers some new small features and > various warnings/deprecations

Re: [RFC] Releasing automake 1.11.2

Peter Rosin skrev 2011-10-30 18:25: > Stefano Lattarini skrev 2011-10-16 17:44: >> Hello automakers. >> >> I think it's about time to release automake 1.11.2 -- the `maint' >> branch contains various bug fixes w.r.t. the 1.11.1 release (some >> of them

Re: Could automake-generated Makefiles required GNU make?

Stefano Lattarini skrev 2011-11-21 21:56: >> Stefano Lattarini wrote: >>>because GNU make is very >>> portable and easy to build and install (and free from bootstrapping >>> problems AFAIK), and because the incompatibilities between different >>> make ver

make dist-lzma and make dist-xz

Hi! I noticed that the changes to "make dist-xz" to default to -e fixed the xz.test on MinGW, but that lzma.test still fails (lzma: (stdin): Not enough memory). Hoping to fix the last fail in the testsuite, I looked into adding one something like LZMA_OPT or something to "make dist-lzma". But in m

Re: make dist-lzma and make dist-xz

Peter Rosin skrev 2011-12-12 10:14: > Hi! > > I noticed that the changes to "make dist-xz" to default to -e fixed > the xz.test on MinGW, but that lzma.test still fails (lzma: (stdin): Not > enough memory). Hoping to fix the last fail in the testsuite, I looked > in

Re: make dist-lzma and make dist-xz

Stefano Lattarini skrev 2011-12-13 18:17: > oOn Monday 12 December 2011, Peter Rosin wrote: >> Hi! >> > Hi Peter. > >> I noticed that the changes to "make dist-xz" to default to -e fixed >> the xz.test on MinGW, but that lzma.test still fails (lzma

Re: make dist-lzma and make dist-xz

Stefano Lattarini skrev 2011-12-14 15:39: > On Wednesday 14 December 2011, Peter Rosin wrote: >> Stefano Lattarini skrev 2011-12-13 18:17: >>> On Monday 12 December 2011, Peter Rosin wrote: >>>> >>>> Hoping to fix the last fail in the testsuite, I looked &

Merging the msvc branch into maint

Hi! Since the msvc branch has been merged into both branch-1.11 and master, it seems natural to also merge it into maint. No? Currently maint holds an outdated version of e.g. lib/compile. Cheers, Peter

Re: Merging the msvc branch into maint

Stefano Lattarini skrev 2011-12-22 09:41: > On 12/22/2011 08:26 AM, Peter Rosin wrote: >> Hi! >> > Hi Peter. > >> Since the msvc branch has been merged into both branch-1.11 and master, >> it seems natural to also merge it into maint. No? >> > I'd r

Re: Merging the msvc branch into maint

Stefano Lattarini skrev 2011-12-22 11:25: > On 12/22/2011 10:54 AM, Peter Rosin wrote: >> Stefano Lattarini skrev 2011-12-22 09:41: >>> On 12/22/2011 08:26 AM, Peter Rosin wrote: >>> >>>> Since the msvc branch has been merged into both branch-1.11 and master,

Re: Automake 1.11.2b test release

Stefano Lattarini skrev 2012-01-25 09:40: > Please report bugs and problems to , and send > general comments and feedback to . Looks as usual on MinGW with cl, with only lzma.test failing as reported previously (can be avoided with XZ_DEFAULTS=--memlimit=150MiB in the environment, but I forgot abo

Re: Automake 1.11.2b test release

Stefano Lattarini skrev 2012-01-26 16:17: > Hi Peter. > > On 01/26/2012 04:08 PM, Peter Rosin wrote: >> Stefano Lattarini skrev 2012-01-25 09:40: >>> Please report bugs and problems to , and send >>> general comments and feedback to . >> >> Looks a

Re: Automake 1.11.2b test release

Stefano Lattarini skrev 2012-01-27 17:16: > On 01/27/2012 03:18 PM, Peter Rosin wrote: *snip* >> And here's from Cygwin "1.7.10s(0.259/5/3) 20120123" (latest snapshot, with >> release candidate "quality", 1.7.10 is coming RSN, as they say). >> >

Re: Automake 1.11.2b test release

Stefano Lattarini skrev 2012-01-27 18:37: > On 01/27/2012 05:43 PM, Peter Rosin wrote: >> Stefano Lattarini skrev 2012-01-27 17:16: >>> On 01/27/2012 03:18 PM, Peter Rosin wrote: >> *snip* >>>> And here's from Cygwin "1.7.10s(0.259/5/3) 20120123&

Re: Automake 1.11.2b test release

Stefano Lattarini skrev 2012-01-27 21:58: > On 01/27/2012 09:40 PM, Peter Rosin wrote: >> Stefano Lattarini skrev 2012-01-27 18:37: >> >>> Thanks for the link. What do you think of the workaround provided by the >>> attached patch? Good to go before 1.11.3? >

Re: automake 1.11.3 check-TESTS and command line length

Stefano Lattarini skrev 2012-02-22 21:54: > On 02/22/2012 09:22 PM, Bob Friesenhahn wrote: >> On Wed, 22 Feb 2012, Stefano Lattarini wrote: >>> I don't understand how that patch could actually work ... If there are >>> too many tests in $(TESTS), there will be too many logs in $(TEST_LOGS), >

Re: Automake 1.11.3b test release

Stefano Lattarini skrev 2012-03-25 16:46: > We are pleased to announce the Automake 1.11.3b test release. *snip* > Please report bugs and problems to , and send > general comments and feedback to . On an up-to-date Cygwin 1.7 install, nothing unexpected. It's just the old problem with lzma.test t

Static library naming

Hi! When you write lib_LIBRARIES = libhello.a you express the desire to build an "hello" archive. Virtually everywhere such an archive is expected to be named, tada, libhello.a Enter Windows. When using any and all toolchains not originating from GNU, such an archive is expected to be named hel

Re: Static library naming

Hi Stefano! Thanks for your input! On 2012-09-20 16:36, Stefano Lattarini wrote: > Adding the Automake-NG list in CC: (see below for the motivation). > > On 09/20/2012 12:49 AM, Peter Rosin wrote: >> Hi! >> > Hi Peter. > >> When you write >> >> lib

Re: Static library naming

On 2012-09-24 09:54, Stefano Lattarini wrote: > On 09/23/2012 11:47 PM, Peter Rosin wrote: >> On 2012-09-20 16:36, Stefano Lattarini wrote: >>> On 09/20/2012 12:49 AM, Peter Rosin wrote: >>>> When you write >>>> >>>> lib_LIBRARIES = libhello

Re: Static library naming

On 2012-09-25 21:33, Stefano Lattarini wrote: > [Dropping Automake-NG list, from the next reply] > > On 09/24/2012 10:51 AM, Peter Rosin wrote: >> >> [MEGA-SNIP] >> >> Yes, because I don't want this to be Automake-NG only. But since >> this scheme is o

Re: Static library naming

On 2012-10-02 16:37, Stefano Lattarini wrote: > Hi Peter, sorry again for the delay. > > On 09/26/2012 10:40 AM, Peter Rosin wrote: >> On 2012-09-25 21:33, Stefano Lattarini wrote: >>> [Dropping Automake-NG list, from the next reply] >>> >>>

Re: bug#13202: Make Microsoft Visual C recognize the .S file extension

Hi Rheinländer! On 2012-12-17 01:41, Rheinländer wrote: > Hi, > > here is a suggestion how to make MSVC (cl.exe) recognize the standard > extension for assembly code in C projects: Just add the compiler > switch /Tc before the file inquestion, or use /TC toforce all files > mentioned on the comma

Re: bug#13202: Make Microsoft Visual C recognize the .S file extension

Hi Jan, Please keep replies on list. On 2012-12-17 11:28, Rheinländer wrote: > Hello Peter, > >> However, I can't get assembly to actually work with -Tc or -TC (see >> below), so what am I doing wrong? >> > > OK, I looked a bit more deeply in it and discovered that my .S file is > actually a C

Re: bug#13324: Improvements to "dist" targets

On 2013-01-02 14:04, Stefano Lattarini wrote: > On 01/02/2013 02:01 PM, Stefano Lattarini wrote: >> On 01/02/2013 02:58 AM, Daniel Herring wrote: >>> On Tue, 1 Jan 2013, Stefano Lattarini wrote: >>> OTOH, what about distribution "tarballs" in '.zip' format? They don't use tar at all ...

Removal of INCLUDES in favour of AM_CPPFLAGS

Hi! >From NEWS in the master branch: - Support for the long-obsolete $(INCLUDES) variable has been finally removed, in favour of the modern equivalent $(AM_CPPFLAGS). Why is this removal important? It forces changes to a hundred (or so) Makefiles in *one* project I'm involved with. T

Re: Removal of INCLUDES in favour of AM_CPPFLAGS

Hi Stefano, On 2013-02-01 10:35, Stefano Lattarini wrote: > On 02/01/2013 09:45 AM, Peter Rosin wrote: >> From NEWS in the master branch: >> >> - Support for the long-obsolete $(INCLUDES) variable has >> been finally removed, in favour of the modern equi

Re: [Automake-NG] Removal of INCLUDES in favour of AM_CPPFLAGS

On 2013-02-02 01:15, Eric Blake wrote: > On 02/01/2013 05:00 PM, Peter Rosin wrote: >> Supporting INCLUDES in automake-NG costs nearly nothing. > > This, however, is a statement I'm not willing to concede; so while I > agree with the decision to deprecate (but not remove) I

Re: bug#13578: [IMPORTANT] Savannah issues

On 2013-02-23 19:06, Stefano Lattarini wrote: > On 02/23/2013 06:46 PM, Stefano Lattarini wrote: >> On 02/21/2013 04:06 PM, Stefano Lattarini wrote: >>> In a couple of days, I will proceed with this "branch moving": >>> >>>* branch-1.13.2 -> maint >>>* maint -> master >>>* master -> nex

Re: bug#13578: [IMPORTANT] Savannah issues

On 2013-02-25 10:16, Stefano Lattarini wrote: > On 02/25/2013 09:14 AM, Peter Rosin wrote: >> On 2013-02-23 19:06, Stefano Lattarini wrote: >>> On 02/23/2013 06:46 PM, Stefano Lattarini wrote: >>>> On 02/21/2013 04:06 PM, Stefano Lattarini wrote: >>>>>

Re: bug#13578: [IMPORTANT] Savannah issues

On 2013-02-26 19:30, Stefano Lattarini wrote: > Hi Peter. > > On 02/26/2013 12:53 AM, Peter Rosin wrote: >> On 2013-02-25 10:16, Stefano Lattarini wrote: >> >>> >>> Note that the users can avoid branch-rewriting issues by renaming their >>> 'm

Re: bug#13578: [IMPORTANT] Savannah issues

On 2013-02-27 10:28, Peter Rosin wrote: > The long winding "eyes glossing over" discussion about version numbers > had nothing in it about branches, except the initial proposal which > stated: > > * None of 'maint', 'master' and 'nex

Re: bug#13578: [IMPORTANT] Savannah issues

On 2013-02-27 11:29, Stefano Lattarini wrote: > On 02/27/2013 10:28 AM, Peter Rosin wrote: >> >> [SNIP] >> >> The long winding "eyes glossing over" discussion about version numbers >> had nothing in it about branches, except the initial proposal whi

Re: bug#13578: [IMPORTANT] Savannah issues

On 2013-02-28 00:39, Stefano Lattarini wrote: > On 02/28/2013 12:00 AM, Peter Rosin wrote: >> >> [SNIP] >> >> What I meant was that you can use (some of) my above proposed merges >> to go forward with the new role for master instead of requiring help >>

Re: C++ and .cp extension

On 2013-05-19 18:57, John Andreasson wrote: > Hi. > > I have an old C++ project that I'm modernizing, and part of the process > involves migrating to Autotools. > > All source files uses the .cp extension. I know it's not common, but many > compilers recognize it as C++. Automake doesn't do that

Re: [FYI] {micro} tests: remove some code duplication

On 2013-05-22 15:57, Stefano Lattarini wrote: > * t/ax/am-test-lib (null_install): New function. > * t/instdir-java.sh: Use it instead of copied & pasted code. > * t/instdir-lisp.sh: Likewise. > * t/instdir-ltlib.sh: Likewise. > * t/instdir-prog.sh: Likewise. > * t/instdir-python.sh: Likewise. > *

Re: Micro releases and testsuite work

On 2013-05-22 20:14, Stefano Lattarini wrote: > Hi Peter. > > On 05/22/2013 06:35 PM, Peter Rosin wrote: >> On 2013-05-22 15:57, Stefano Lattarini wrote: >>> * t/ax/am-test-lib (null_install): New function. >>> * t/instdir-java.sh: Use it instead of copied &

Re: More control over 'make dist'

On 2016-09-14 11:33, Michal Privoznik wrote: > Dear list, > > I'm a libvirt devel and I've ran into interesting problem. I'd like to > hear your opinions on it. > > Libvirt is a virtualization library that uses XML to store a virtual > machine config. We have couple of tests in our repository too

cl -c -o trouble in libtool am-subdir.at

Hi! For some years now, I've been working on and off on adding MSVC support w/o wrapper scripts to libtool (see the pr-msvc-support branch in libtool git) and have run into an issue that has been brought up here before. http://lists.gnu.org/archive/html/automake/2007-06/msg00083.html I was tryi

make distcheck is not using the specified compiler

Hi! I'm trying to get in position for running the testsuite on MSYS using the Microsoft C/C++ Compiler (and don't really know what to expect). As a first step I tried this on a fresh checkout: ./bootstrap ./configure CC=cl CFLAGS=-MD CXX=cl CXXFLAGS=-MD make and that triggered a distcheck of a

Re: RE : call for help/crazy idea: nmake sup port

Den 2010-08-13 19:18 skrev Ralf Wildenhues: > I would like to thank everyone who provided input on this topic. > It certainly helps when considering where to go. One conclusion > from this is that we should get Peter's MSVC support finished > and completed for Automake 1.12 and the next Libtool re

Static libraries not following the libfoo.a naming convention

Hi! I have been wondering when I was going to run into this problem, and now it has happened (in the Libtool testsuite, tests/demo-deplibs.test). Automake has rules for creating static libraries like so (taken from that test case): EXTRA_LIBRARIES = libhell0.a libhell0_a_SOURCES = libhell0_a_LIB

Re: Static libraries not following the libfoo.a naming convention

Den 2010-09-23 20:59 skrev Ralf Wildenhues: > Hi Peter, > > * Peter Rosin wrote on Thu, Sep 23, 2010 at 10:01:16AM CEST: >> I have been wondering when I was going to run into this problem, > > Me too. :-) >> and >> now it has happened (in the Libtool t

Re: Automake and AR

Den 2011-01-04 16:23 skrev NightStrike: > On Thu, Dec 9, 2010 at 10:11 AM, NightStrike wrote: >> On Sat, Nov 27, 2010 at 10:25 AM, NightStrike wrote: >>> On Sun, Oct 31, 2010 at 9:37 AM, NightStrike wrote: On Fri, Oct 22, 2010 at 1:07 PM, NightStrike wrote: > On Wed, Mar 3, 2010 at 3:5