Re: [Mingw-w64-public] aclocal.m4 and Makefile.am out of sync

2016-10-03 Thread Adrien Nader 
On Mon, Oct 03, 2016, David Wohlferd wrote:
> On 10/2/2016 6:38 PM, JonY wrote:
> >On 10/3/2016 06:37, David Wohlferd wrote:
> >>So, my testing didn't turn up any problems.  The patch is pretty
> >>big (1,389,398), so I have compressed it and uploaded it to
> >>http://www.LimeGreenSocks.com/gen2.7z (where it is only 82,083).
> >>
> >>Just a reminder: Despite the size, this is 100% regenerated code,
> >>mostly in the build-aux directories.
> >>
> >>Comments (especially about whether we need the beta config.guess)
> >>welcome.  What needs to happen to get this approved to Push?
> >>
> 
> I'm sorry, I'm a bit thick.  Can you clarify?
> 
> >Since it is all regenerated code, I'm OK with it.
> 
> Is this the same as "approved to push?"
> 
> >config.guess is
> >nice, but not essential, no one has complained about unsupported
> >platforms, yet.
> 
> Does this mean you want to use the most-recently-released version?
> Or the beta version (which is even more recent)?  The patch I posted
> uses the released version.  But it could be that "no one has
> complained" because the beta is what is currently checked in.
> 
> While an argument can be made for either, my recommendation is to go
> with the 'released,' and only use the beta if there is a specific
> requirement.  But since "going backward" like this might break
> something (maybe someone did complain at some point?), I felt the
> need to ask.
> 
> My tests were with the 'released' version, but I'm prepared to
> re-test if the beta is preferred.  As the "approver," I assume you
> decide?
> 
> I believe that if I update config.guess, I'm supposed to update
> config.sub too (not knowing the answer to this is another reason to
> stick with the 'released' version).  I have attached a patch for
> config.guess + config.sub to show what has changed.  Note that this
> is going backwards (turning the 'beta' into the 'most recently
> released').

I quickly went through the diff and I've found the following:

>  +amd64:MSYS*:*:* | x86_64:MSYS*:*:*)
>  +   echo x86_64-unknown-msys
>  +   exit ;;

There are also changes that could be related to ARM support ("earm").

Oh and iOS and ASM.js but I think they don't matter much to us (although
maybe we'll soon have that portable POSIX environment in javascript and
we'll build boost with it).

Most of the diff is either quoting or removed and added platforms but
there are also a couple other changes. 

I think it's safer to keep the version that is currently checked in. I
prefer versions from released tarballs but sometimes we'll also need to
handle new platforms. For these cases, I'm perfectly fine with
unreleased versions (autotools perfectly enables such usecases) but I'd
like to see a request somewhere or a slightly more complete commit
message (i.e. "adds support for X and Y") so it's easier to track in the
future.

-- 
Adrien Nader

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] aclocal.m4 and Makefile.am out of sync

2016-10-03 Thread David Wohlferd 

On 10/2/2016 6:38 PM, JonY wrote:

On 10/3/2016 06:37, David Wohlferd wrote:

So, my testing didn't turn up any problems.  The patch is pretty
big (1,389,398), so I have compressed it and uploaded it to
http://www.LimeGreenSocks.com/gen2.7z (where it is only 82,083).

Just a reminder: Despite the size, this is 100% regenerated code,
mostly in the build-aux directories.

Comments (especially about whether we need the beta config.guess)
welcome.  What needs to happen to get this approved to Push?



I'm sorry, I'm a bit thick.  Can you clarify?


Since it is all regenerated code, I'm OK with it.


Is this the same as "approved to push?"


config.guess is
nice, but not essential, no one has complained about unsupported
platforms, yet.


Does this mean you want to use the most-recently-released version? Or 
the beta version (which is even more recent)?  The patch I posted uses 
the released version.  But it could be that "no one has complained" 
because the beta is what is currently checked in.


While an argument can be made for either, my recommendation is to go 
with the 'released,' and only use the beta if there is a specific 
requirement.  But since "going backward" like this might break something 
(maybe someone did complain at some point?), I felt the need to ask.


My tests were with the 'released' version, but I'm prepared to re-test 
if the beta is preferred.  As the "approver," I assume you decide?


I believe that if I update config.guess, I'm supposed to update 
config.sub too (not knowing the answer to this is another reason to 
stick with the 'released' version).  I have attached a patch for 
config.guess + config.sub to show what has changed.  Note that this is 
going backwards (turning the 'beta' into the 'most recently released').


dw
diff --git a/mingw-w64-tools/widl/build-aux/config.guess b/mingw-w64-tools/widl/build-aux/config.guess
index 0967f2a..b450eb4 100755
--- a/mingw-w64-tools/widl/build-aux/config.guess
+++ b/mingw-w64-tools/widl/build-aux/config.guess
@@ -1,8 +1,8 @@
 #! /bin/sh
 # Attempt to guess a canonical system name.
-#   Copyright 1992-2016 Free Software Foundation, Inc.
+#   Copyright 1992-2014 Free Software Foundation, Inc.
 
-timestamp='2016-04-02'
+timestamp='2014-11-04'
 
 # This file is free software; you can redistribute it and/or modify it
 # under the terms of the GNU General Public License as published by
@@ -27,7 +27,7 @@ timestamp='2016-04-02'
 # Originally written by Per Bothner; maintained since 2000 by Ben Elliston.
 #
 # You can get the latest version of this script from:
-# http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess
+# http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD
 #
 # Please send patches to .
 
@@ -50,7 +50,7 @@ version="\
 GNU config.guess ($timestamp)
 
 Originally written by Per Bothner.
-Copyright 1992-2016 Free Software Foundation, Inc.
+Copyright 1992-2014 Free Software Foundation, Inc.
 
 This is free software; see the source for copying conditions.  There is NO
 warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE."
@@ -168,27 +168,20 @@ case "${UNAME_MACHINE}:${UNAME_SYSTEM}:${UNAME_RELEASE}:${UNAME_VERSION}" in
 	# Note: NetBSD doesn't particularly care about the vendor
 	# portion of the name.  We always set it to "unknown".
 	sysctl="sysctl -n hw.machine_arch"
-	UNAME_MACHINE_ARCH=`(uname -p 2>/dev/null || \
-	/sbin/$sysctl 2>/dev/null || \
-	/usr/sbin/$sysctl 2>/dev/null || \
-	echo unknown)`
+	UNAME_MACHINE_ARCH=`(/sbin/$sysctl 2>/dev/null || \
+	/usr/sbin/$sysctl 2>/dev/null || echo unknown)`
 	case "${UNAME_MACHINE_ARCH}" in
 	armeb) machine=armeb-unknown ;;
 	arm*) machine=arm-unknown ;;
 	sh3el) machine=shl-unknown ;;
 	sh3eb) machine=sh-unknown ;;
 	sh5el) machine=sh5le-unknown ;;
-	earmv*)
-		arch=`echo ${UNAME_MACHINE_ARCH} | sed -e 's,^e\(armv[0-9]\).*$,\1,'`
-		endian=`echo ${UNAME_MACHINE_ARCH} | sed -ne 's,^.*\(eb\)$,\1,p'`
-		machine=${arch}${endian}-unknown
-		;;
 	*) machine=${UNAME_MACHINE_ARCH}-unknown ;;
 	esac
 	# The Operating System including object format, if it has switched
 	# to ELF recently, or will in the future.
 	case "${UNAME_MACHINE_ARCH}" in
-	arm*|earm*|i386|m68k|ns32k|sh3*|sparc|vax)
+	arm*|i386|m68k|ns32k|sh3*|sparc|vax)
 		eval $set_cc_for_build
 		if echo __ELF__ | $CC_FOR_BUILD -E - 2>/dev/null \
 			| grep -q __ELF__
@@ -204,13 +197,6 @@ case "${UNAME_MACHINE}:${UNAME_SYSTEM}:${UNAME_RELEASE}:${UNAME_VERSION}" in
 		os=netbsd
 		;;
 	esac
-	# Determine ABI tags.
-	case "${UNAME_MACHINE_ARCH}" in
-	earm*)
-		expr='s/^earmv[0-9]/-eabi/;s/eb$//'
-		abi=`echo ${UNAME_MACHINE_ARCH} | sed -e "$expr"`
-		;;
-	esac
 	# The OS release
 	# Debian GNU/NetBSD machines have a different userland, and
 	# thus, need a distinct triplet. However, they do not need
@@ -221,13 +207,13 @@ case

Re: [Mingw-w64-public] aclocal.m4 and Makefile.am out of sync

2016-10-02 Thread JonY 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 10/3/2016 06:37, David Wohlferd wrote:
> 
> So, my testing didn't turn up any problems.  The patch is pretty
> big (1,389,398), so I have compressed it and uploaded it to 
> http://www.LimeGreenSocks.com/gen2.7z (where it is only 82,083).
> 
> Just a reminder: Despite the size, this is 100% regenerated code,
> mostly in the build-aux directories.
> 
> Comments (especially about whether we need the beta config.guess) 
> welcome.  What needs to happen to get this approved to Push?
> 

Since it is all regenerated code, I'm OK with it. config.guess is
nice, but not essential, no one has complained about unsupported
platforms, yet.


-BEGIN PGP SIGNATURE-

iF4EAREIAAYFAlfxtoMACgkQk721PNTrx0AIwAD+N8aweG6eE2pCsg/5BripipuH
b65iL31uKreDSv29XScA/23K6oY5rSMOWn1lujCo7kIL4mpGeIv+/GsfrXF9AQ5H
=lfs/
-END PGP SIGNATURE-
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] aclocal.m4 and Makefile.am out of sync

2016-10-02 Thread David Wohlferd 
On 10/1/2016 4:37 PM, David Wohlferd wrote:
> On 9/24/2016 7:23 PM, David Wohlferd wrote:
>> On 9/24/2016 4:55 AM, NightStrike wrote:
>>> On Sep 23, 2016 8:08 PM, "David Wohlferd"  
>>> wrote:
 Ok. With that change in place, I have run
autoreconf -fiv

 in the root directory of mingw-w64.  That regenerated a bunch of 
 files.

 To test this, I have run configure, make and make install for each of
 x86, x64 and arm.  These all seem to build correctly.

 Nightstrike: Running "make distcheck" now runs a bit further than
 before.  However:

 - For x86, all the initial checks complete, but when it tries doing 
 its
 own VPATH build, it fails because of include path issues (it tries to
 build mingw-w64-crt in isolation from mingw-w64-headers). But since 
 the
 normal build succeeds, I don't believe this is a problem.
 - For x64, it fails because pseh is "missing."  Obviously it is 
 missing
 because it's not supported on x64.  I'm not sure why distcheck doesn't
 skip it.
 - For arm, it fails because libmangle is missing.  Not sure how to get
 it to skip this either.
>>> Use AM_DISTCHECK_CONFIGURE_FLAGS to set configure options 
>>> specifically used
>>> for the distcheck target. For instance, maybe --disable-pseh (if 
>>> that's a
>>> thing, I don't know)
>> Actually, "disabled" is the default.  If you want it to build, you must
>> explicitly enable it (--with-libraries=pseh or --with-libraries=all).
>> It's not immediately clear to me why distcheck thinks it should check
>> parts that are disabled.
>>
>> Is this important enough to track down?  Or can this patch be approved
>> without it?
>
> I was getting ready to nudge this thread to get it approved for push, 
> when I noticed something.  While running "autoreconf -fiv" does walk 
> down subdirectories, it doesn't walk ALL our subdirectories.
>
> So I tried again.
>
> This time I explicitly deleted all the build-aux directories, as well 
> as all makefile.in, configure. and aclocal.m4 to force autoreconf to 
> really regenerate them.  After running "autoreconf -fiv", I looked to 
> see which directories didn't get these files re-generated.  I then 
> changed to those directories and run "autoreconf -fiv" from there.  
> THAT got everything.
>
> Looking at the new patch, I noticed something else.  In some cases, 
> the config.guess that is being generated is OLDER than the one that is 
> checked in.  After analysis, it appears that someone (sezero?) has 
> checked in a beta version of this file in a few places.  Was this done 
> on purpose to resolve a problem?  It seems like we should either stay 
> with "released" versions, or use the same version everywhere.  Opinions?
>
> I have started re-testing, but if someone wants to shed some light on 
> this config.guess thing, I can make any needed changes before posting 
> this (increasingly large) patch.

So, my testing didn't turn up any problems.  The patch is pretty big 
(1,389,398), so I have compressed it and uploaded it to 
http://www.LimeGreenSocks.com/gen2.7z (where it is only 82,083).

Just a reminder: Despite the size, this is 100% regenerated code, mostly 
in the build-aux directories.

Comments (especially about whether we need the beta config.guess) 
welcome.  What needs to happen to get this approved to Push?

dw

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] aclocal.m4 and Makefile.am out of sync

2016-10-01 Thread David Wohlferd 
On 9/24/2016 7:23 PM, David Wohlferd wrote:
> On 9/24/2016 4:55 AM, NightStrike wrote:
>> On Sep 23, 2016 8:08 PM, "David Wohlferd"  wrote:
>>> Ok. With that change in place, I have run
>>>autoreconf -fiv
>>>
>>> in the root directory of mingw-w64.  That regenerated a bunch of files.
>>>
>>> To test this, I have run configure, make and make install for each of
>>> x86, x64 and arm.  These all seem to build correctly.
>>>
>>> Nightstrike: Running "make distcheck" now runs a bit further than
>>> before.  However:
>>>
>>> - For x86, all the initial checks complete, but when it tries doing its
>>> own VPATH build, it fails because of include path issues (it tries to
>>> build mingw-w64-crt in isolation from mingw-w64-headers). But since the
>>> normal build succeeds, I don't believe this is a problem.
>>> - For x64, it fails because pseh is "missing."  Obviously it is missing
>>> because it's not supported on x64.  I'm not sure why distcheck doesn't
>>> skip it.
>>> - For arm, it fails because libmangle is missing.  Not sure how to get
>>> it to skip this either.
>> Use AM_DISTCHECK_CONFIGURE_FLAGS to set configure options specifically used
>> for the distcheck target. For instance, maybe --disable-pseh  (if that's a
>> thing, I don't know)
> Actually, "disabled" is the default.  If you want it to build, you must
> explicitly enable it (--with-libraries=pseh or --with-libraries=all).
> It's not immediately clear to me why distcheck thinks it should check
> parts that are disabled.
>
> Is this important enough to track down?  Or can this patch be approved
> without it?

I was getting ready to nudge this thread to get it approved for push, 
when I noticed something.  While running "autoreconf -fiv" does walk 
down subdirectories, it doesn't walk ALL our subdirectories.

So I tried again.

This time I explicitly deleted all the build-aux directories, as well as 
all makefile.in, configure. and aclocal.m4 to force autoreconf to really 
regenerate them.  After running "autoreconf -fiv", I looked to see which 
directories didn't get these files re-generated.  I then changed to 
those directories and run "autoreconf -fiv" from there.  THAT got 
everything.

Looking at the new patch, I noticed something else.  In some cases, the 
config.guess that is being generated is OLDER than the one that is 
checked in.  After analysis, it appears that someone (sezero?) has 
checked in a beta version of this file in a few places.  Was this done 
on purpose to resolve a problem?  It seems like we should either stay 
with "released" versions, or use the same version everywhere.  Opinions?

I have started re-testing, but if someone wants to shed some light on 
this config.guess thing, I can make any needed changes before posting 
this (increasingly large) patch.

dw

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] aclocal.m4 and Makefile.am out of sync

2016-09-24 Thread David Wohlferd 
On 9/24/2016 4:55 AM, NightStrike wrote:
> On Sep 23, 2016 8:08 PM, "David Wohlferd"  wrote:
>> On 9/23/2016 5:08 AM, JonY wrote:
>>> On 9/23/2016 09:50, David Wohlferd wrote:
 On 9/22/2016 5:53 AM, JonY wrote:
> On 9/22/2016 20:23, JonY wrote:
>> just remove the mpdecimal directory, the dfp/*.c stuff should
>> still work, likewise for the pformat.c changes. I'm doing just
>> that since yesterday, running build tests. SF ate my GPG signed
>> mail.
>>
>> Use format-patch -D to ommit the contents of the deleted
>> files.
> Patch attached.
 Looks good to me.
>>> Done.
>> Ok.  With that change in place, I have run
>>
>>   autoreconf -fiv
>>
>> in the root directory of mingw-w64.  That regenerated a bunch of files.
>>
>> To test this, I have run configure, make and make install for each of
>> x86, x64 and arm.  These all seem to build correctly.
>>
>> Nightstrike: Running "make distcheck" now runs a bit further than
>> before.  However:
>>
>> - For x86, all the initial checks complete, but when it tries doing its
>> own VPATH build, it fails because of include path issues (it tries to
>> build mingw-w64-crt in isolation from mingw-w64-headers). But since the
>> normal build succeeds, I don't believe this is a problem.
>> - For x64, it fails because pseh is "missing."  Obviously it is missing
>> because it's not supported on x64.  I'm not sure why distcheck doesn't
>> skip it.
>> - For arm, it fails because libmangle is missing.  Not sure how to get
>> it to skip this either.
> Use AM_DISTCHECK_CONFIGURE_FLAGS to set configure options specifically used
> for the distcheck target. For instance, maybe --disable-pseh  (if that's a
> thing, I don't know)

Actually, "disabled" is the default.  If you want it to build, you must 
explicitly enable it (--with-libraries=pseh or --with-libraries=all).  
It's not immediately clear to me why distcheck thinks it should check 
parts that are disabled.

Is this important enough to track down?  Or can this patch be approved 
without it?

dw

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] aclocal.m4 and Makefile.am out of sync

2016-09-24 Thread NightStrike 
On Sep 23, 2016 8:08 PM, "David Wohlferd"  wrote:
>
> On 9/23/2016 5:08 AM, JonY wrote:
> > On 9/23/2016 09:50, David Wohlferd wrote:
> >> On 9/22/2016 5:53 AM, JonY wrote:
> >>> On 9/22/2016 20:23, JonY wrote:
>  just remove the mpdecimal directory, the dfp/*.c stuff should
>  still work, likewise for the pformat.c changes. I'm doing just
>  that since yesterday, running build tests. SF ate my GPG signed
>  mail.
> 
>  Use format-patch -D to ommit the contents of the deleted
>  files.
> >>> Patch attached.
> >> Looks good to me.
> >>
> > Done.
>
> Ok.  With that change in place, I have run
>
>  autoreconf -fiv
>
> in the root directory of mingw-w64.  That regenerated a bunch of files.
>
> To test this, I have run configure, make and make install for each of
> x86, x64 and arm.  These all seem to build correctly.
>
> Nightstrike: Running "make distcheck" now runs a bit further than
> before.  However:
>
> - For x86, all the initial checks complete, but when it tries doing its
> own VPATH build, it fails because of include path issues (it tries to
> build mingw-w64-crt in isolation from mingw-w64-headers). But since the
> normal build succeeds, I don't believe this is a problem.
> - For x64, it fails because pseh is "missing."  Obviously it is missing
> because it's not supported on x64.  I'm not sure why distcheck doesn't
> skip it.
> - For arm, it fails because libmangle is missing.  Not sure how to get
> it to skip this either.

Use AM_DISTCHECK_CONFIGURE_FLAGS to set configure options specifically used
for the distcheck target. For instance, maybe --disable-pseh  (if that's a
thing, I don't know)
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] aclocal.m4 and Makefile.am out of sync

2016-09-23 Thread JonY 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 9/23/2016 09:50, David Wohlferd wrote:
> On 9/22/2016 5:53 AM, JonY wrote:
>> On 9/22/2016 20:23, JonY wrote:
>>> just remove the mpdecimal directory, the dfp/*.c stuff should 
>>> still work, likewise for the pformat.c changes. I'm doing just
>>> that since yesterday, running build tests. SF ate my GPG signed
>>> mail.
>>> 
>>> Use format-patch -D to ommit the contents of the deleted
>>> files.
>> Patch attached.
> 
> Looks good to me.
> 

Done.


-BEGIN PGP SIGNATURE-

iF4EAREIAAYFAlflG1YACgkQk721PNTrx0AUvAD9FcldwhiHMRwekNhafUSvYpZp
KWRQ5N+mysHUiP06NwEA/3MAKU7fh9FGmV/6sH7ZJui7y2ug3rmhsIxD7xCICyyL
=8be6
-END PGP SIGNATURE-
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] aclocal.m4 and Makefile.am out of sync

2016-09-22 Thread David Wohlferd 
On 9/22/2016 5:53 AM, JonY wrote:
> On 9/22/2016 20:23, JonY wrote:
>> just remove the mpdecimal directory, the dfp/*.c stuff should
>> still work, likewise for the pformat.c changes. I'm doing just that
>> since yesterday, running build tests. SF ate my GPG signed mail.
>>
>> Use format-patch -D to ommit the contents of the deleted files.
> Patch attached.

Looks good to me.

dw

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] aclocal.m4 and Makefile.am out of sync

2016-09-22 Thread JonY 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 9/22/2016 20:23, JonY wrote:
> 
> just remove the mpdecimal directory, the dfp/*.c stuff should
> still work, likewise for the pformat.c changes. I'm doing just that
> since yesterday, running build tests. SF ate my GPG signed mail.
> 
> Use format-patch -D to ommit the contents of the deleted files.
> 
> 

Patch attached.
-BEGIN PGP SIGNATURE-

iF4EAREIAAYFAlfj1FgACgkQk721PNTrx0CVEgD/dUUbYzW4NeAwMvc75+tkFIx7
xukA6puhzWe9+3j4I+8BAIqgU3pv7SQYXmyscF9PyP/S2p3mzISM5b/P6wbitStR
=PGli
-END PGP SIGNATURE-
>From ada9d92039d3faf3b2c5202ec588a817c718b1b4 Mon Sep 17 00:00:00 2001
From: Jonathan Yong <10wa...@gmail.com>
Date: Thu, 22 Sep 2016 20:48:38 +0800
Subject: [PATCH 1/2] Remove dead mpdecimal code, it was never called

mpdecimal was originally planned for use to support DFP math,
but it never gone far. Remove it for now.

Signed-off-by: Jonathan Yong <10wa...@gmail.com>
---
 mingw-w64-crt/Makefile.am  |   205 +-
 mingw-w64-crt/math/DFP/mpdecimal/.hg_archival.txt  | 5 -
 mingw-w64-crt/math/DFP/mpdecimal/CHANGELOG.txt |   141 -
 mingw-w64-crt/math/DFP/mpdecimal/COMPILERS.txt |   109 -
 mingw-w64-crt/math/DFP/mpdecimal/INSTALL.txt   |85 -
 mingw-w64-crt/math/DFP/mpdecimal/LICENSE.txt   |26 -
 mingw-w64-crt/math/DFP/mpdecimal/Makefile.in   |53 -
 mingw-w64-crt/math/DFP/mpdecimal/README.txt|35 -
 mingw-w64-crt/math/DFP/mpdecimal/config.guess  |  1454 ---
 mingw-w64-crt/math/DFP/mpdecimal/config.h.in   |   100 -
 mingw-w64-crt/math/DFP/mpdecimal/config.sub|  1815 ---
 mingw-w64-crt/math/DFP/mpdecimal/configure |  5871 -
 mingw-w64-crt/math/DFP/mpdecimal/configure.ac  |   428 -
 mingw-w64-crt/math/DFP/mpdecimal/doc/LICENSE.txt   |66 -
 .../math/DFP/mpdecimal/doc/_static/ajax-loader.gif |   Bin 673 -> 0 bytes
 .../math/DFP/mpdecimal/doc/_static/basic.css   |   536 -
 .../DFP/mpdecimal/doc/_static/comment-bright.png   |   Bin 3500 -> 0 bytes
 .../DFP/mpdecimal/doc/_static/comment-close.png|   Bin 3578 -> 0 bytes
 .../math/DFP/mpdecimal/doc/_static/comment.png |   Bin 3445 -> 0 bytes
 .../math/DFP/mpdecimal/doc/_static/default.css |   256 -
 .../math/DFP/mpdecimal/doc/_static/doctools.js |   235 -
 .../DFP/mpdecimal/doc/_static/down-pressed.png |   Bin 368 -> 0 bytes
 .../math/DFP/mpdecimal/doc/_static/down.png|   Bin 363 -> 0 bytes
 .../math/DFP/mpdecimal/doc/_static/file.png|   Bin 392 -> 0 bytes
 .../math/DFP/mpdecimal/doc/_static/jquery.js   | 2 -
 .../math/DFP/mpdecimal/doc/_static/minus.png   |   Bin 199 -> 0 bytes
 .../DFP/mpdecimal/doc/_static/mpdecimal-doc.css|   351 -
 .../math/DFP/mpdecimal/doc/_static/plus.png|   Bin 199 -> 0 bytes
 .../math/DFP/mpdecimal/doc/_static/pygments.css|60 -
 .../math/DFP/mpdecimal/doc/_static/searchtools.js  |   622 -
 .../math/DFP/mpdecimal/doc/_static/sidebar.js  |   159 -
 .../math/DFP/mpdecimal/doc/_static/underscore.js   |31 -
 .../math/DFP/mpdecimal/doc/_static/up-pressed.png  |   Bin 372 -> 0 bytes
 .../math/DFP/mpdecimal/doc/_static/up.png  |   Bin 363 -> 0 bytes
 .../math/DFP/mpdecimal/doc/_static/websupport.js   |   808 --
 .../math/DFP/mpdecimal/doc/arithmetic.html |   794 --
 .../math/DFP/mpdecimal/doc/assign-convert.html |   358 -
 .../math/DFP/mpdecimal/doc/attributes.html |   282 -
 mingw-w64-crt/math/DFP/mpdecimal/doc/context.html  |   569 -
 mingw-w64-crt/math/DFP/mpdecimal/doc/decimals.html |   157 -
 .../math/DFP/mpdecimal/doc/functions.html  |   610 -
 mingw-w64-crt/math/DFP/mpdecimal/doc/index.html|   278 -
 mingw-w64-crt/math/DFP/mpdecimal/doc/memory.html   |   235 -
 mingw-w64-crt/math/DFP/mpdecimal/doc/objects.inv   |   Bin 1854 -> 0 bytes
 mingw-w64-crt/math/DFP/mpdecimal/doc/search.html   |95 -
 .../math/DFP/mpdecimal/doc/searchindex.js  | 1 -
 mingw-w64-crt/math/DFP/mpdecimal/doc/various.html  |   431 -
 .../math/DFP/mpdecimal/examples/README.txt | 8 -
 .../math/DFP/mpdecimal/examples/compare.c  |77 -
 mingw-w64-crt/math/DFP/mpdecimal/examples/div.c|77 -
 mingw-w64-crt/math/DFP/mpdecimal/examples/divmod.c |82 -
 .../math/DFP/mpdecimal/examples/multiply.c |77 -
 mingw-w64-crt/math/DFP/mpdecimal/examples/pow.c|77 -
 mingw-w64-crt/math/DFP/mpdecimal/examples/powmod.c |80 -
 mingw-w64-crt/math/DFP/mpdecimal/examples/shift.c  |77 -
 mingw-w64-crt/math/DFP/mpdecimal/examples/sqrt.c   |74 -
 mingw-w64-crt/math/DFP/mpdecimal/install-sh|   527 -
 .../math/DFP/mpdecimal/libmpdec/Makefile.in|   149 -
 .../math/DFP/mpdecimal/libmpdec/Makefile.vc|   211 -
 .../math/DFP/mpdecimal/libmpdec/README.txt |87 -
 .../math/DFP/mpdecimal/libmpdec/basearith.c|   658 -
 .../math/DFP/mpdecimal/libmpdec/basearith.h|   222 -

Re: [Mingw-w64-public] aclocal.m4 and Makefile.am out of sync

2016-09-22 Thread JonY 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 9/22/2016 07:15, David Wohlferd wrote:
> 
> Creating patches that delete files makes for REALLY big patches.
> Instead of me emailing the 8MB file, just pretend that the attached
> file also deletes the entire mingw-w64-crt/math/DFP/mpdecimal
> directory, in addition to removing all references to it from
> mingw-w64-crt/Makefile.am.
> 
> Note that it does NOT remove mingw-w64-crt/math/DFP.
> 
> So, we have:
> 
> - DFP2.patch (previous email) which just changes EXTRA_DIST to
> remove the DFP/mpdecimal stuff. - DFP3.patch (current email) which
> removes the entire mingw-w64-crt/math/DFP/mpdecimal directory and
> all references to it.
> 
> I suppose the next step would be to remove the entire 
> --enable-experimental=dfp.  Is that what you were proposing?  Looks
> like a much bigger change (__dfp_expansion macro?
> stdio\mingw_pformat.c?).
> 
> JonY, please either approve one of these patches or provide more
> guidance.
> 
> dw

just remove the mpdecimal directory, the dfp/*.c stuff should still
work, likewise for the pformat.c changes. I'm doing just that since
yesterday, running build tests. SF ate my GPG signed mail.

Use format-patch -D to ommit the contents of the deleted files.

-BEGIN PGP SIGNATURE-

iF4EAREIAAYFAlfjzUoACgkQk721PNTrx0C/GQD/QtVKcKU5+3XINsU/wbkbLUoF
ENoAZF4H9LoCJq6LcNMA/1Elqj5qxmn6FcEVmk48dCO2GjSj6Rmd+Q4FHZ3+pcyJ
=GGcw
-END PGP SIGNATURE-
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] aclocal.m4 and Makefile.am out of sync

2016-09-21 Thread David Wohlferd 

On 9/20/2016 3:39 PM, David Wohlferd wrote:

On 9/20/2016 3:01 AM, JonY wrote:

On 9/20/2016 14:29, David Wohlferd wrote:

1) The paths for the math/DFP stuff are totally messed up.
Directory names include a version number (2.3) which our tree has
removed, some directory names have changed (s/cmd/examples) and
some have been re-orged (mpdecimal-2.3/fnt.c ->
mpdecimal/libmpdec/fnt.c).  I think I have fixed all these.

The libmpdec directory (and Makefile.am entries) stuff can be removed,
I was too ambitious to support DFP, but never really had the time to
go deep.


Ahh.

So, I have removed the DFP stuff from EXTRA_DIST (attached). That's an 
easier patch and solves my distcheck problems.  That's enough for me 
to proceed.


But it sounds like you are talking about more?

If it will help, I'm willing to take a crack at removing whatever you 
say should go.  But I'm reluctant to remove things I don't understand 
without clearer instructions.  For example, are we getting rid of all 
the ENABLE_DFP experimental stuff?  Deleting all of 
mingw-w64-crt/math/DFP from the tree?  Or just 
mingw-w64-crt/math/DFP/mpdecimal?


Creating patches that delete files makes for REALLY big patches. Instead 
of me emailing the 8MB file, just pretend that the attached file also 
deletes the entire mingw-w64-crt/math/DFP/mpdecimal directory, in 
addition to removing all references to it from mingw-w64-crt/Makefile.am.


Note that it does NOT remove mingw-w64-crt/math/DFP.

So, we have:

- DFP2.patch (previous email) which just changes EXTRA_DIST to remove 
the DFP/mpdecimal stuff.
- DFP3.patch (current email) which removes the entire 
mingw-w64-crt/math/DFP/mpdecimal directory and all references to it.


I suppose the next step would be to remove the entire 
--enable-experimental=dfp.  Is that what you were proposing?  Looks like 
a much bigger change (__dfp_expansion macro? stdio\mingw_pformat.c?).


JonY, please either approve one of these patches or provide more guidance.

dw
diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index 886fcf0..cc54f5b 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -71,35 +71,6 @@ _libm_dummy.c:
 
 src_libm=_libm_dummy.c
 
-lib32/DFP_src_%.dfp.obj: math/DFP/mpdecimal/libmpdec/%.c
-	$(COMPILE) $(CPPFLAGS32) -Wno-unknown-pragmas -std=gnu99 -DCONFIG_32 -DASM -DPPRO -DHAVE_GCC_ASM_FOR_X87=1 -DHAVE_INTTYPES_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRINGS_H=1 -DHAVE_STRING_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_UNISTD_H=1 -DPACKAGE_BUGREPORT='"mpdecimal-b...@bytereef.org"' -DPACKAGE_NAME='"mpdecimal"' -DPACKAGE_STRING='"mpdecimal 2.4.0"' -DPACKAGE_TARNAME='"mpdecimal"' -DPACKAGE_URL='"http://www.bytereef.org/mpdecimal/index.html;' -DPACKAGE_VERSION='"2.4.0"' -DSIZEOF_SIZE_T=4 -DSIZEOF___UINT128_T=0 -DSTDC_HEADERS=1 -O2 -Dmpdecimal_header=\"mpdecimal-i686.h\" -c $< -o $@
-
-lib64/DFP_src_%.dfp.obj: math/DFP/mpdecimal/libmpdec/%.c
-	$(COMPILE) $(CPPFLAGS64) -Wno-unknown-pragmas -std=gnu99 -DCONFIG_64 -DASM -DHAVE_GCC_ASM_FOR_X64=1 -DHAVE_GCC_ASM_FOR_X87=1 -DHAVE_INTTYPES_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRINGS_H=1 -DHAVE_STRING_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_UINT128_T=1 -DHAVE_UNISTD_H=1 -DPACKAGE_BUGREPORT='"mpdecimal-b...@bytereef.org"' -DPACKAGE_NAME='"mpdecimal"' -DPACKAGE_STRING='"mpdecimal 2.4.0"' -DPACKAGE_TARNAME='"mpdecimal"' -DPACKAGE_URL='"http://www.bytereef.org/mpdecimal/index.html;' -DPACKAGE_VERSION='"2.4.0"' -DSIZEOF_SIZE_T=8 -DSIZEOF___UINT128_T=16 -DSTDC_HEADERS=1 -O2 -Dmpdecimal_header=\"mpdecimal-x86_64.h\" -c $< -o $@
-
-if ENABLE_DFP
-obj_dfpsrc32 = \
-lib32/DFP_src_basearith.dfp.obj lib32/DFP_src_context.dfp.obj lib32/DFP_src_constants.dfp.obj lib32/DFP_src_convolute.dfp.obj lib32/DFP_src_crt.dfp.obj \
-lib32/DFP_src_mpdecimal.dfp.obj lib32/DFP_src_mpsignal.dfp.obj lib32/DFP_src_difradix2.dfp.obj lib32/DFP_src_fnt.dfp.obj lib32/DFP_src_fourstep.dfp.obj \
-lib32/DFP_src_io.dfp.obj lib32/DFP_src_memory.dfp.obj lib32/DFP_src_numbertheory.dfp.obj lib32/DFP_src_sixstep.dfp.obj lib32/DFP_src_transpose.dfp.obj
-
-obj_dfpsrc64 = \
-lib64/DFP_src_basearith.dfp.obj lib64/DFP_src_context.dfp.obj lib64/DFP_src_constants.dfp.obj lib64/DFP_src_convolute.dfp.obj lib64/DFP_src_crt.dfp.obj \
-lib64/DFP_src_mpdecimal.dfp.obj lib64/DFP_src_mpsignal.dfp.obj lib64/DFP_src_difradix2.dfp.obj lib64/DFP_src_fnt.dfp.obj lib64/DFP_src_fourstep.dfp.obj \
-lib64/DFP_src_io.dfp.obj lib64/DFP_src_memory.dfp.obj lib64/DFP_src_numbertheory.dfp.obj lib64/DFP_src_sixstep.dfp.obj lib64/DFP_src_transpose.dfp.obj
-
-src_dfp_math = \
-math/DFP/__fpclassifyd32.c math/DFP/__fpclassifyd64.c math/DFP/__fpclassifyd128.c \
-math/DFP/__isnand32.c math/DFP/__isnand64.c math/DFP/__isnand128.c \
-math/DFP/__signbitd32.c math/DFP/__signbitd64.c math/DFP/__signbitd128.c \
-math/DFP/isinfd32.c math/DFP/isinfd64.c math/DFP/isinfd128.c
-
-else
-obj_dfpsrc32 =
-obj_dfpsrc64 =
-src_dfp_math =
-endif
-

Re: [Mingw-w64-public] aclocal.m4 and Makefile.am out of sync

2016-09-20 Thread David Wohlferd 

On 9/20/2016 3:01 AM, JonY wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 9/20/2016 14:29, David Wohlferd wrote:

1) The paths for the math/DFP stuff are totally messed up.
Directory names include a version number (2.3) which our tree has
removed, some directory names have changed (s/cmd/examples) and
some have been re-orged (mpdecimal-2.3/fnt.c ->
mpdecimal/libmpdec/fnt.c).  I think I have fixed all these.

The libmpdec directory (and Makefile.am entries) stuff can be removed,
I was too ambitious to support DFP, but never really had the time to
go deep.


Ahh.

So, I have removed the DFP stuff from EXTRA_DIST (attached).  That's an 
easier patch and solves my distcheck problems.  That's enough for me to 
proceed.


But it sounds like you are talking about more?

If it will help, I'm willing to take a crack at removing whatever you 
say should go.  But I'm reluctant to remove things I don't understand 
without clearer instructions.  For example, are we getting rid of all 
the ENABLE_DFP experimental stuff?  Deleting all of 
mingw-w64-crt/math/DFP from the tree?  Or just 
mingw-w64-crt/math/DFP/mpdecimal?


dw
diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index 886fcf0..6241f76 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -1512,189 +1512,6 @@ EXTRA_DIST += revstamp.h \
   profile/COPYING \
   profile/CYGWIN_LICENSE
 
-EXTRA_DIST += math/DFP/mpdecimal-2.3/.hg_archival.txt \
-math/DFP/mpdecimal-2.3/basearith.c \
-math/DFP/mpdecimal-2.3/basearith.h \
-math/DFP/mpdecimal-2.3/bench.c \
-math/DFP/mpdecimal-2.3/bits.h \
-math/DFP/mpdecimal-2.3/cdecimal2.c \
-math/DFP/mpdecimal-2.3/cdecimal3.c \
-math/DFP/mpdecimal-2.3/CHANGELOG.txt \
-math/DFP/mpdecimal-2.3/cmd/compare.c \
-math/DFP/mpdecimal-2.3/cmd/div.c \
-math/DFP/mpdecimal-2.3/cmd/divmod.c \
-math/DFP/mpdecimal-2.3/cmd/multiply.c \
-math/DFP/mpdecimal-2.3/cmd/pow.c \
-math/DFP/mpdecimal-2.3/cmd/powmod.c \
-math/DFP/mpdecimal-2.3/cmd/README.txt \
-math/DFP/mpdecimal-2.3/cmd/shift.c \
-math/DFP/mpdecimal-2.3/cmd/sqrt.c \
-math/DFP/mpdecimal-2.3/config.h.in \
-math/DFP/mpdecimal-2.3/configure \
-math/DFP/mpdecimal-2.3/configure.in \
-math/DFP/mpdecimal-2.3/constants.c \
-math/DFP/mpdecimal-2.3/constants.h \
-math/DFP/mpdecimal-2.3/context.c \
-math/DFP/mpdecimal-2.3/convolute.c \
-math/DFP/mpdecimal-2.3/convolute.h \
-math/DFP/mpdecimal-2.3/crt.c \
-math/DFP/mpdecimal-2.3/crt.h \
-math/DFP/mpdecimal-2.3/difradix2.c \
-math/DFP/mpdecimal-2.3/difradix2.h \
-math/DFP/mpdecimal-2.3/doc/cdecimal/index.html \
-math/DFP/mpdecimal-2.3/doc/index.html \
-math/DFP/mpdecimal-2.3/doc/libmpdec/arithmetic.html \
-math/DFP/mpdecimal-2.3/doc/libmpdec/assign-convert.html \
-math/DFP/mpdecimal-2.3/doc/libmpdec/attributes.html \
-math/DFP/mpdecimal-2.3/doc/libmpdec/context.html \
-math/DFP/mpdecimal-2.3/doc/libmpdec/decimals.html \
-math/DFP/mpdecimal-2.3/doc/libmpdec/functions.html \
-math/DFP/mpdecimal-2.3/doc/libmpdec/index.html \
-math/DFP/mpdecimal-2.3/doc/libmpdec/memory.html \
-math/DFP/mpdecimal-2.3/doc/libmpdec/various.html \
-math/DFP/mpdecimal-2.3/doc/LICENSE.txt \
-math/DFP/mpdecimal-2.3/doc/objects.inv \
-math/DFP/mpdecimal-2.3/doc/search.html \
-math/DFP/mpdecimal-2.3/doc/searchindex.js \
-math/DFP/mpdecimal-2.3/doc/_static/basic.css \
-math/DFP/mpdecimal-2.3/doc/_static/default.css \
-math/DFP/mpdecimal-2.3/doc/_static/doctools.js \
-math/DFP/mpdecimal-2.3/doc/_static/file.png \
-math/DFP/mpdecimal-2.3/doc/_static/jquery.js \
-math/DFP/mpdecimal-2.3/doc/_static/minus.png \
-math/DFP/mpdecimal-2.3/doc/_static/mpdecimal-doc.css \
-math/DFP/mpdecimal-2.3/doc/_static/plus.png \
-math/DFP/mpdecimal-2.3/doc/_static/pygments.css \
-math/DFP/mpdecimal-2.3/doc/_static/searchtools.js \
-math/DFP/mpdecimal-2.3/doc/_static/sidebar.js \
-math/DFP/mpdecimal-2.3/doc/_static/underscore.js \
-math/DFP/mpdecimal-2.3/docstrings.h \
-math/DFP/mpdecimal-2.3/fnt.c \
-math/DFP/mpdecimal-2.3/fnt.h \
-math/DFP/mpdecimal-2.3/fourstep.c \
-math/DFP/mpdecimal-2.3/fourstep.h \
-math/DFP/mpdecimal-2.3/io.c \
-math/DFP/mpdecimal-2.3/io.h \
-math/DFP/mpdecimal-2.3/LIBINSTALL.txt \
-math/DFP/mpdecimal-2.3/LICENSE.txt \
-math/DFP/mpdecimal-2.3/literature/mpdecimal.lisp \
-math/DFP/mpdecimal-2.3/literature/README.txt \
-math/DFP/mpdecimal-2.3/literature/umodarith.lisp \
-math/DFP/mpdecimal-2.3/Makefile.in \
-math/DFP/mpdecimal-2.3/Makefile.vc \
-math/DFP/mpdecimal-2.3/memory.c \
-math/DFP/mpdecimal-2.3/memory.h \
-math/DFP/mpdecimal-2.3/mpdecimal-i686.h \
-math/DFP/mpdecimal-2.3/mpdecimal-x86_64.h \
-math/DFP/mpdecimal-2.3/mpdecimal.c \
-math/DFP/mpdecimal-2.3/mpdecimal.h.in \
-math/DFP/mpdecimal-2.3/mpdecimal32vc.h \
-math/DFP/mpdecimal-2.3/mpdecimal64vc.h \
-math/DFP/mpdecimal-2.3/mpsignal.c \
-math/DFP/mpdecimal-2.3/mptest.h \
-math/DFP/mpdecimal-2.3/mptypes.h \
-math/DFP/mpdecimal-2.3/numbertheory.c \
-math/DFP/mpdecimal-2.3/numbertheory.h \
-math/DFP/mpdecimal-2.3/PKG-INFO \
-math/DFP/mpdecimal-2.3/PYINSTALL.txt \

Re: [Mingw-w64-public] aclocal.m4 and Makefile.am out of sync

2016-09-20 Thread David Wohlferd 

On 8/12/2016 5:34 AM, NightStrike wrote:

On Thu, Aug 11, 2016 at 2:05 AM, dw  wrote:

I have been told that "autoreconf -fiv" regenerates all the files using
the current version.  But after seeing the dozen files it changed and
realizing I didn't actually know what any of them were, I chickened out.

If there's something I can do to help, let me know.

Yes, that's all that is required (other than testing).  I used to use
"make distcheck" to test things, but I don't know if that still works.
You can certainly try doing that before and after in each sub project.
The thing with make distcheck is that it verifies that every
distributable file is accounted for in the build system, which isn't
always the case.  If you feel like trying that, and you get errors,
let me know.


So, I have finally gotten back to this.

To recap:  My goal is to make sure all the generated files are in sync 
with each other (for example Makefile.in should be generated by the same 
version of autoconf/automake as aclocal.m4).


As nightstrike suggested, I have tried doing "make distcheck" before 
changing anything to find any existing problems.  This produced a BUNCH 
of failures.  They all come from EXTRA_DIST in mingw-w64-crt/Makefile.am 
and fall into 2 categories:


1) The paths for the math/DFP stuff are totally messed up. Directory 
names include a version number (2.3) which our tree has removed, some 
directory names have changed (s/cmd/examples) and some have been 
re-orged (mpdecimal-2.3/fnt.c -> mpdecimal/libmpdec/fnt.c).  I think I 
have fixed all these.
2) There are currently 69 files listed that don't appear in our tree (I 
don't see them being generated either).  I have moved all of the missing 
files from EXTRA_DIST to FILES_DONT_EXIST in the attached patch to keep 
distcheck from complaining.  Also note the 27 files I've added to 
SKIPPED_FILES that *are* in our tree, but *aren't* currently listed in 
EXTRA_DIST.


Arguably both SKIPPED_FILES and FILES_DONT_EXIST should be removed from 
this file before being pushed.  They serve no purpose other than as 
documentation of something I don't understand.  Unless someone tells me 
a better use for them (like moving all of SKIPPED_FILES into 
EXTRA_DIST?).  I could really use some guidance here.


Other than this, the regen seems to be working fine.  But I want to fix 
this DFP stuff first.  Help?


dw
diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index 886fcf0..2dc1678 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -1512,188 +1512,222 @@ EXTRA_DIST += revstamp.h \
   profile/COPYING \
   profile/CYGWIN_LICENSE
 
-EXTRA_DIST += math/DFP/mpdecimal-2.3/.hg_archival.txt \
-math/DFP/mpdecimal-2.3/basearith.c \
-math/DFP/mpdecimal-2.3/basearith.h \
-math/DFP/mpdecimal-2.3/bench.c \
-math/DFP/mpdecimal-2.3/bits.h \
-math/DFP/mpdecimal-2.3/cdecimal2.c \
-math/DFP/mpdecimal-2.3/cdecimal3.c \
-math/DFP/mpdecimal-2.3/CHANGELOG.txt \
-math/DFP/mpdecimal-2.3/cmd/compare.c \
-math/DFP/mpdecimal-2.3/cmd/div.c \
-math/DFP/mpdecimal-2.3/cmd/divmod.c \
-math/DFP/mpdecimal-2.3/cmd/multiply.c \
-math/DFP/mpdecimal-2.3/cmd/pow.c \
-math/DFP/mpdecimal-2.3/cmd/powmod.c \
-math/DFP/mpdecimal-2.3/cmd/README.txt \
-math/DFP/mpdecimal-2.3/cmd/shift.c \
-math/DFP/mpdecimal-2.3/cmd/sqrt.c \
-math/DFP/mpdecimal-2.3/config.h.in \
-math/DFP/mpdecimal-2.3/configure \
-math/DFP/mpdecimal-2.3/configure.in \
-math/DFP/mpdecimal-2.3/constants.c \
-math/DFP/mpdecimal-2.3/constants.h \
-math/DFP/mpdecimal-2.3/context.c \
-math/DFP/mpdecimal-2.3/convolute.c \
-math/DFP/mpdecimal-2.3/convolute.h \
-math/DFP/mpdecimal-2.3/crt.c \
-math/DFP/mpdecimal-2.3/crt.h \
-math/DFP/mpdecimal-2.3/difradix2.c \
-math/DFP/mpdecimal-2.3/difradix2.h \
-math/DFP/mpdecimal-2.3/doc/cdecimal/index.html \
-math/DFP/mpdecimal-2.3/doc/index.html \
-math/DFP/mpdecimal-2.3/doc/libmpdec/arithmetic.html \
-math/DFP/mpdecimal-2.3/doc/libmpdec/assign-convert.html \
-math/DFP/mpdecimal-2.3/doc/libmpdec/attributes.html \
-math/DFP/mpdecimal-2.3/doc/libmpdec/context.html \
-math/DFP/mpdecimal-2.3/doc/libmpdec/decimals.html \
-math/DFP/mpdecimal-2.3/doc/libmpdec/functions.html \
-math/DFP/mpdecimal-2.3/doc/libmpdec/index.html \
-math/DFP/mpdecimal-2.3/doc/libmpdec/memory.html \
-math/DFP/mpdecimal-2.3/doc/libmpdec/various.html \
-math/DFP/mpdecimal-2.3/doc/LICENSE.txt \
-math/DFP/mpdecimal-2.3/doc/objects.inv \
-math/DFP/mpdecimal-2.3/doc/search.html \
-math/DFP/mpdecimal-2.3/doc/searchindex.js \
-math/DFP/mpdecimal-2.3/doc/_static/basic.css \
-math/DFP/mpdecimal-2.3/doc/_static/default.css \
-math/DFP/mpdecimal-2.3/doc/_static/doctools.js \
-math/DFP/mpdecimal-2.3/doc/_static/file.png \
-math/DFP/mpdecimal-2.3/doc/_static/jquery.js \
-math/DFP/mpdecimal-2.3/doc/_static/minus.png \
-math/DFP/mpdecimal-2.3/doc/_static/mpdecimal-doc.css \
-math/DFP/mpdecimal-2.3/doc/_static/plus.png \
-math/DFP/mpdecimal-2.3/doc/_static/pygments.css \

Re: [Mingw-w64-public] aclocal.m4 and Makefile.am out of sync

2016-08-11 Thread dw 

>> Since I need to regenerate Makefile.in, I need to decide what to do:
> Make one commit that updates aclocal to v1.15.

Committed and pushed.

> Make a second commit that
> applies your desired changes to both Makefile.am and Makefile.in.

Committed and pushed.

>> Hopefully someone who knows more about this stuff than I do can check in
>> the 'right' fix to get things back in sync.
> I can take a crack at it, at least to make everything consistent. 
> There are
> ways to force a minimum version, too, to prevent regressions.

I have been told that "autoreconf -fiv" regenerates all the files using 
the current version.  But after seeing the dozen files it changed and 
realizing I didn't actually know what any of them were, I chickened out.

If there's something I can do to help, let me know.

dw
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] aclocal.m4 and Makefile.am out of sync

2016-08-10 Thread NightStrike 
On Aug 10, 2016 5:44 PM, "dw"  wrote:
>
> The checked-in mingw-w64-crt/Makefile.in was generated with 1.15.
> However the associated aclocal.m4 is generated with 1.14.1.  I don't
> know much about the build files, but is mixing and matching like this a
> good idea?

Nope

> Since I need to regenerate Makefile.in, I need to decide what to do:

Make one commit that updates aclocal to v1.15. Make a second commit that
applies your desired changes to both Makefile.am and Makefile.in.

> d) I could regenerate all the build files in the entire project to 1.15
> (some are as old as 1.11.6).

I used to maintain this regularly. In reality, automake doesn't have a
current maintainer, so one more update would be the last for a while.

> But honestly, I'm not particularly comfortable doing any of these.
>
> I generally assume that newer versions fix problems or have other
> benefits, but sometimes they can introduce other issues.  For all I know
> there's a good reason things are the way they are.  And I'm certainly
> not going to be the best qualified to answer any questions or fix any
> problems that may arise as a result of c or d.

When Ralf was the maintainer, it was much easier to blindly update. Now,
new versions do break stuff. But, breakages are typically easy to deal with
swiftly.

> Hopefully someone who knows more about this stuff than I do can check in
> the 'right' fix to get things back in sync.

I can take a crack at it, at least to make everything consistent. There are
ways to force a minimum version, too, to prevent regressions.
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public