Re: [Mingw-w64-public] aclocal.m4 and Makefile.am out of sync
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
Re: [Mingw-w64-public] aclocal.m4 and Makefile.am out of sync
>> 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
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. -- 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
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 \ -math/DFP/mpdecimal-2.3/doc/_static/searchtools.js \ -math/DFP/mpde
Re: [Mingw-w64-public] aclocal.m4 and Makefile.am out of sync
-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. -BEGIN PGP SIGNATURE- iF4EAREIAAYFAlfhCOYACgkQk721PNTrx0BB1gD/Sy9DefnKZOjFYSRUVOzgtUZl BUMMbzbapQatoE+3WtIA/jqJsRQ70CPGNXVGjTVL1b6POU4CQ5JP7JaYX9vRD0gd =iBzh -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
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 \ -math/DFP/mpdecimal
Re: [Mingw-w64-public] aclocal.m4 and Makefile.am out of sync
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
-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
-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 - mingw-w64-crt/math/DFP/mpdeci
Re: [Mingw-w64-public] aclocal.m4 and Makefile.am out of sync
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
-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
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. Such being the case, I'm prepared to push these changes, pending approval. Note that while the attached file is large-ish, it is all generated code from the "autoreconf -fiv". Since this patch is too big for the list (380k vs 120k max), I have posted it to http://www.limegreensocks.com/gen.patch. 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
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
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
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
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
-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
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 "${UNAME_MACHINE}:${UNAME_SYSTEM}:${UNAME_RELEASE}:${UNAME_VERSION}" in release
Re: [Mingw-w64-public] aclocal.m4 and Makefile.am out of sync
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
On 10/3/2016 10:31 PM, Adrien Nader wrote: > 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. You are reading it backward. Since the version of config.guess that is checked in is the beta, when I 'downgrade' it to the released version (1.15), it adds back the things the beta removed. IOW, the beta doesn't "add" support for amd64:MSYS*:*:*, it's removing it. > 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) Since we aren't grabbing these files at a fixed point (ie a release), the version we are using could have any amount of weirdness in it that would get deleted the next day. IOW, "perfectly enables" might work when taking the 1.15 files and back-proping them to 1.14. But grabbing "today's" checkin seems really risky. Other than at a release, how can we know what's "stable?" > 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. This is the key point. The risk from mixing/matching can only be justified if there is some clear benefit. But nowhere in this (1 month old) thread has anyone stated that reason. Maybe the reason we were doing this got fixed a long time ago, but since no one remembers what it was, we just keep grabbing random config.guess files. My vote is to check in code using the released/supported version of the software. If someone wants/needs to update to a later config.guess, let them post a patch (and a reason) and get approval. FWIW, the patch (with 100% regenerated files) using the 'released' version of config.guess is still at http://www.LimeGreenSocks.com/gen2.7z. If using a beta config.guess is what is needed to get this approved, just let me know specifically where I should get it from (and the other support files [config.sub? Others?] you want me to grab) and I'll update, retest and resubmit this patch. Jony? Ktietz? Decision time? 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
Hi, I don't want to re-launch this thread while another one is now more current but my (short) comment felt more appropriate here. On Sun, Oct 09, 2016, David Wohlferd wrote: > On 10/3/2016 10:31 PM, Adrien Nader wrote: > > 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. > > You are reading it backward. Since the version of config.guess that is > checked in is the beta, when I 'downgrade' it to the released version > (1.15), it adds back the things the beta removed. > > IOW, the beta doesn't "add" support for amd64:MSYS*:*:*, it's removing it. I'm actually not reading it one way or the other: I am saying that the code is changed so there can be a difference for an environment we know is used to build mingw-w64. It's now been two weeks and there has been no comment from the interested party which we know reads this mailing-list. I think we can safely conclude it is safe to go on without specific consideration for that case since both versions seem to be fine. -- 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