From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 102369 invoked by alias); 26 Feb 2018 20:02:09 -0000 Mailing-List: contact newlib-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: newlib-owner@sourceware.org Received: (qmail 102357 invoked by uid 89); 26 Feb 2018 20:02:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy= X-HELO: mout.kundenserver.de Received: from mout.kundenserver.de (HELO mout.kundenserver.de) (212.227.126.135) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 26 Feb 2018 20:02:07 +0000 Received: from [192.168.178.45] ([95.91.246.199]) by mrelayeu.kundenserver.de (mreue004 [212.227.15.167]) with ESMTPSA (Nemesis) id 0MKMnS-1epqTT0TVG-001gVa for ; Mon, 26 Feb 2018 21:02:05 +0100 Subject: Re: Unicode update of width and other character properties To: newlib@sourceware.org References: <20170807103034.GB18389@calimero.vinschen.de> <714181b2-c625-c911-8516-af4cba868f09@towo.net> <20170808083024.GA23158@calimero.vinschen.de> <0690aecd-4c52-edec-1ee8-af94b7f38e56@towo.net> <20171203093041.GA7126@calimero.vinschen.de> <20171204090318.GB21472@calimero.vinschen.de> <62dbc36b-7636-a358-355f-e588a325c924@towo.net> <20180226172040.GD3037@calimero.vinschen.de> From: Thomas Wolff Message-ID: <80075f84-c541-95c2-07fd-6dad2f9a01ac@towo.net> Date: Mon, 26 Feb 2018 20:02:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180226172040.GD3037@calimero.vinschen.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-UI-Out-Filterresults: notjunk:1;V01:K0:gwg0fb2rcN8=:D+zEkptYR2Uu37IhQNLcVE SMrQusz103VY2B/kWfYf621q63zldAdKR79+SG6xFskHH+CZ3NEmM/5d77QryU4oq2k8tYx4K +YKhjB2JKUIWpTC603gLlKlPPbK3GnCfSL67P/1drhBr1VLTIjKh+ZkmUqwn7j+ZknUzBZnoI x+h9SbUzlCYQKxPOXdpcITgbkOPnhp1E0R6giT2pnOaxtUh+bWEO7B0a/b7hGvDlkIvNVnm8D xQKYNMHOYx/ktnmDe2/ItnlElOVIK7YTw2LRw9v/FPQK+a/DMluS2sarjALFX8vMXqMbWmXWS pH+C/CyU/fnBc31azzyGPUeeofoEy3/nPaJciOvkO2AdvNBJpxNouWp7Yg85LZhxPlLbazBLH zH7xUwNY+Di31aHtxME1OMF1QnRAVEBYcd//zRlSMCHw9elESQjUMT97XAmLU5FAJw61StKrA 7a9HLBqlTRsOQednnEcbBlM2o24icv4i0odU93hgG2wjUrz6VVYQOi6RA+9Nd3QUUDkafQp3x 3O/jbgWvb+qfinsDKGbwkHgj/SJIiJD5HA4bYcIUizIGLKivfrMug/iCeGqv5o/hr6UKdzPeq Wb6weFPDj7YNU0jPZtN8cWWITWaGfobh8KXFqS2lRKsSOiRQyt64SN75ANgMUUZGoXdDbRyvQ d8iBeiOBURUNtiX9zCcfNEhXAF5H0XJYAm9qoqPLTis43qP+b5ZOm0+SBKq8wYy92BOrNSWXp l3oPRWoRbxpSLYN6c1IOnaWL+XBh7DgyWBJqeoYibzXetIzb+bcj9vn773M= X-IsSubscribed: yes X-SW-Source: 2018/txt/msg00180.txt.bz2 Am 26.02.2018 um 18:20 schrieb Corinna Vinschen: > On Feb 25 18:14, Thomas Wolff wrote: >> I have finally revamped, manually rebased, and repackaged my Unicode data >> patches which I'll send in separate mail. >> ... > ... > or *attach* the patches, one per mail. That will do, thanks. >> There are two patches: >> libc/string: wcwidth using generated width data, with data generated from >> Unicode 10.0 >> libc/ctype: isw* and tow* functions using generated case conversion and >> character class data, with Unicode 10.0 data >> For both, generation script and a Makefile.widthdata / Makefile.chardata is >> included. As these are to be used in the source directory, >> not the binary target directory, in case of future Unicode update, they are >> not related to the other Makefiles. > Eh, what? If you read back, I had no problems with your patches 2 and > 3, only with patch 1 adding new makefiles. So the only thing I actually > asked for was to integrate the creation of the generated tables into > Makefile.am and now you're telling me this is not what you changed...? First I added an include to the generation makefile into Makefile.am, then it occurred to me that the generated makefile resides in the target hierarchy while the generation should probably be invoked in the source directory, so I removed it again. I'm not sure about the best or preferred invocation interface for such a step. Maybe I should just provide the generation scripts (mk*) and leave it up to you to integrate them into the Makefile.am. >> In ctype/, there is one new source (categories.c) which should be compiled >> separately but although I tried to include it in Makefile.am, >> I could not get the build process to compile it. So the current solution is >> to include it from one of the other sources (the one that also maintains the >> case conversion table). > That's a workaround, not a solution. When you change Makefile.am you > have to regenerate Makefile.in, obviously. > > However, since regenerating Makefile.in for newlib is (unfortunately, > for historical reasons) non-obvious, you can just go ahead and manually > add categories.* to Makefile.in where it belongs, kind of like the > attached. Thanks for the patch. I'll resubmit the wcwidth patch soon, maybe you can tell me how you'd like the data generation to be invoked, or I can submit it just with the script. I'll submit the ctype patch later; all works fine on my Windows 10 system but there is some obscure trouble on a Windows 7 system which I'd like to check out first. And there's also a locale patch which I presented a separate mail. Thomas