From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sonic306-21.consmr.mail.ir2.yahoo.com (sonic306-21.consmr.mail.ir2.yahoo.com [77.238.176.207]) by sourceware.org (Postfix) with ESMTPS id 106E43858404 for ; Sun, 30 Jan 2022 22:22:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 106E43858404 X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643581352; bh=EQqvqkQpugH71tDLqcFNXCwEwndENtcmG27MQBQmSoM=; h=X-Sonic-MF:Date:Subject:From:To:From:Subject; b=rpjmHRslNJbntlpsRF1afCaqd7Mxxo0tabixJTs0yzsR3w3wPNC0lss3XQ7WcCiU4iPo55EfwMJCL27ljhWXY39/JVhkINObMlCex5aB99IPtpUzeToGY5P7Gu0aA2aj4a8RlySXu5KzYglXwCorCevmnQ4oULMbhPUF2evofE2xjOrujdga2zxZtVBFGnfO1W5GqwSKWWZyboP3Fw/Z2meSiXogxH6G9KxNGtU3HkGmz0nwZB1luGKpSTDKd0FG7ujENqRAOcFsvGDOhH0AKE+UQKd4bOGqEI4Oz5bjQLq+QRSSyvtIZl95yfYA6bzi4vR+nv9QmuW9eCn00e37Pw== X-YMail-OSG: kc5LomwVM1kPH5dq7wHQQZZGm1hQQ5PnXDLtxNV2YLeZsO.17g40NwBF36Vkpfn QshSHq2PJRSbs8QBVnhiSjlu.d2WqvzIWnlAVS9WzSGoLKmH7GIXAZ0albX9A50P5eCVIkGLbm6L PpSSP3NIt7ixpsorMLpOS0icOAEcfFzjvbCJRKX6XUa6fbGNhadAnS2QArnREWiQs9eDyIdjnL.5 ygVRfgNoyiTbtIzTEk8ajwrZEdhssJg6F2.6cvMQm1utjY8E9J8Ge19UtSFJmA0WFkzmzpO2WktU s2XTVmzJPvjNSWeDC7a.gw.ZKctlfrsf8_05EFXecAUYGt4Rch_QEA1xLeEnxWRJNI6SgQFRSmnp bWh1Ty9z8NSzUPWgt1a033GzvYRQHvd6TeGMunm0EZ_jaeOzmZhSEcd27_.JlX5QglHI5dBeTt8B Cq2WGIgaMxiO26X0WZQgiUC6ne7DWQNJ0BE2It6wyroecjUYYu.eOJWNvWzv5S5dHZhKE9bY0DKQ DzB8WPfYoJpBrGaqKH9e_YcEbfRABM1UZZ8qRTAs1oSmQjk5Qcg_sF9KsRAfvAJKmGAjshjEQOFp m4kOCL9e3Qlwz.Xc0tZ9b5HyS0TIgw8d1XFMyKp77TpA68ijteaYZrSq0goBmoMwSUgQcSvwwzJ5 6tnKPTe0LxGfyqm3PXPWvga4xCAnxxdpzSjlsQlDENoqoua4f1Ktgms3Qm4h2R8k.OzpQD4nDc49 hnSVZ4rHFuroEF1NOu692GlFtu0K0frhQ1nNGmFWZ.xFkwZ81DGZfBkLjmG52nQ7hS7RIvwcJY73 0RXG_TUdICnWQFSqMKTzbt7YlByLhrKicBcIVXKeVZE.8LKyOrJO1q1qSrWYUVvHdsRJPUjzDpyN AinWEoVZJ7CAAHqpIWgDchSRjNOfT7ErI4S2zVFXBIA07MRbaP.dB_mxl5mEq.o6pjcM4jf0WbTV Aqoqylbd398h_wQCZe.5Z.GcPgrHmLaDiEvmc2YnrdS467AGyxA5WVdq7imIj8Z9GZvNGvvw7e0e QU7m_EhtYrwDTHou6B4ZToWrLoXqSWf3kvnYMB3N.zxcWeJydApCpeDTGoUYXxTQZWsmhcLS5rMi m5BCrPvk.u3o268ZjtSJf4NNbvJCSRD3lWIwc7cd5tOLsw52ZXm_BNJDraiFj8JNK5yfWSSsDp9k 6_gzHLFNWojbkdefRLY6BoVhblXDn9aAR7JQPg_bmCK9sYmw2QeIXLt4rnM.6vYGw8I3Nezjlbg1 eOHDuU6VGpTOLk8SxZlCWrIop1qUPzapoRY8rmgE7bYGTNlaEnMAVnERt.64_s9IFAwlSG5awJbM 1OdtPQMmLWTA5MCBRJ.XcLrgjYFMhD3cxIrGDBOSutacyQ_EFHDS9eRXbCHUIg0SsRZu3NH4wfzs TkYyzk.t6CwboFGxcVCEQdmebAvQIcS6xYB2RG4WoDvi94mLAG0EYNp1eVanXNlZh6owPoE6qmFO E6259AEBYhfCB4vvvT9j6Q3dt7R2T2c3lgJzffYBD2zFqFyoRq.xUstr6kaJanApT4d_WXOo1ci0 FdUEx8aKxp4u_noh69rdDDO8GtJ.vTgz3cCc3leE8.t3D3Zo.iEOEuuunX1ZqGqWuInEUOynYNp3 7VZ3oGza1KVBFDLdHCmDFkiOXuFKP5tuw.XFrulWVGZkXYfbw4nfl4aJsqtkkIDCUpVHOJp_8fA9 KV_7JruiWchyXF1fVTKlX0mN7__tol.AvOqzRX56xIvRL38q16z5kPTHuXJgYAjBWGAcJi9TOpLU XH2Pc3td8z6sKcoYD7uB547WKKcx9RxjLKebGTOvYW00EElPxr.MzMtGBY6SojuRDSDGqSUtL.Nd gbrnDEkZkt6AWmJ7sdT5EghHm3.fdHmxn406.1pqW.FzeY40WiRpVFISYd1QyXQYneVjzezO32zX VbOZQN7lKtayLfi3qyIJvXG0anhNihAUJN4AF4jKAvq.wmRgN8wIt5Iu9I_1kGVjfHubQPKFwBrC qctDD9ypTaT5QhQkLsO1YOQgeIt01nUcZOcE.C3RaiP.N2gUTdoZ0DIfFrwiciqRY9AQpXl7SNbl jaEGDNZiicRNI6Xm9pgCV4GYy4qT3X0fAcyg6yjnZP_03acWfOEuSGVuGNVrTMvgG7mf8Y2HWt7V iNSu7N.MO2SIB92Yhwv5eWDMoOx4DENdom14A.uiF7R6gRBnlyD9Qxjb5XYn5JvSYWvnAFVKlvOW 2Mo0sRHRjXl4QtqgKPXCqLsQoZ3ZgPlcYk.DY2L8QHuy55MFUZhuu X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.ir2.yahoo.com with HTTP; Sun, 30 Jan 2022 22:22:32 +0000 Received: by kubenode503.mail-prod1.omega.ir2.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 3d5943ee2e72c01012f0886fdabac225; Sun, 30 Jan 2022 22:22:29 +0000 (UTC) Message-ID: Date: Sun, 30 Jan 2022 23:22:28 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: Question about autoreconf to regenerate configuration files Content-Language: en-GB References: <26fff1a3-7743-e0ce-f7a6-70b39a030118@embedded-brains.de> <41deefa7-d1ae-18f2-6a8e-25e002d85ed6@yahoo.de> <2bc01390-3a5b-fd2d-822c-c4cd9a96f744@yahoo.de> From: "R. Diez" Cc: Newlib , Matthew Joyce , joel@rtems.org To: Mike Frysinger In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: WebService/1.1.19615 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: newlib@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Newlib mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2022 22:22:41 -0000 >>> [...] >>> there is only one set of top-level files. they get manually synced from >>> gcc to the other projects by devs who notice & need the fixes. >> >> OK, I gather that copying those files across from GCC is the standard practice. >> But why do we need to keep doing that in Newlib? According to the (outdated) >> cross toolchain build instructions, when combining the tree the GCC versions should prevail. > > i don't understand what you're asking. the top-level provides files that > newlib uses. they need to be kept up-to-date. see AC_CONFIG_AUX_DIR use > throughout the tree. So the Newlib build system is a mix of something specific to Newlib, and some bits shared with GCC. But I would still like to understand what files are shared between Newlib, GCC, GDB, Binutils, etc. I gathered that all AC_CONFIG_AUX_DIR around Newlib point to the top-level directory, which is not a good idea. Auxiliary files should be placed in a subdirectory in order to reduce clutter in the top-level project directory. This also prevents the configuration script from looking for helper scripts outside the project, in ../ and ../../ , possibly finding older versions or incompatible tools with the same name. But I understand that we are sharing at least the multilib logic with GCC, probably config/multi.m4 , and those shared files perhaps expect AC_CONFIG_AUX_DIR to point to the top-level directory. So we shouldn't change it in Newlib. Talking about config/multi.m4: this file is almost identical to the one in gcc-10.3.0, so it has fallen only a little behind. But other files like config/override.m4 have changed more. Maybe it is time to upgrade the copies in Newlib then, if they are truly shared and used? Does Newlib have to include copies of those files anyway? If you are building multilibs, is that not specific to GCC? Wouldn't you need the GCC sources at hand anyway? Does Newlib have to have files like include/gdb/sim-arm.h ? I thought the simulators lived with GDB, so is that not part of GDB? If you are building the simulators, do you not need the GDB sources anyway? Does it make sense to have a MAINTAINERS file in Newlib talking about directories like binutils/ which do not exist? Shouldn't we have a different one called MAINTAINERS.Newlib? And the same with ChangeLog. Why do we need to have our own copy of configure.ac at top-level? If you will be building in a "combined tree", then the other configure.ac copy should override ours, be it GCC, GDB or Binutils. If we are building just Newlib for another compiler or outside a "combined tree", would we be using that same configure.ac at top level? Or do you have to configure newlib/ and libgloss/ separately anyway? Is it worth sharing the Autotools files with GCC at all? On the one hand, we can reuse GCC's multilib implementation, but on the other hand, I can imagine that dealing with integration problems as GCC etc. evolve is problematic. How do other libc libraries like Musl cope? Do they share the same Autoconf logic with GCC, or do they implement their own multilib logic? >> It is not like anybody would take Newlib without GCC and use those top-level files (the >> 'configure' script) to build say just Newlib and Binutils, is it? > > why not ? i have a gdb/binutils dir that i link just newlib & libgloss > into. the GNU simulator is part of those trees, and it pulls ABI info > out of newlib & libgloss. being able to iterate on those parts without > rebuilding gcc is helpful. Newlib alone is not going to suffice, because it is a "leaf" component. You will always need something else, like GCC or the GDB simulators. GDB brings its own configure.ac, config/ , etc. Should these not override the ones in Newlib when building in this smaller "combined tree"? Or does that overriding rule not apply here? The main problem is that you need too much undocumented information in order to be able to maintain Newlib, to create a new release, or simply to contribute or to troubleshoot it. Or maybe I haven't found yet the place where all this is documented. I would have expected to see documentation like this: ---------8<---------8<---------8<--------- README-Newlib.txt In order to create a Newlib release: 1) Sync the build files shared with GCC. The Newlib sources are designed to be used inside a "combined tree" with GCC and/or GDB etc. in order to build several toolchain components at the same time. The files to synchronise from GCC (the master copy) are: xxx config/ yyy/ zzz 2) Regenerate the Autoconf files, and check the new versions in. The exact Autools versions that should be used are listed in file README-maintainer-mode . Use these commands (or better, provide a script): ( cd newlib && time autoreconf --force --verbose --warnings=all ) ... 3) Test building in a "combined tree" with recent GCC and GDB simulator versions. 4) The maintainer (or the user?) can rebuild the Newlib documentation like this: 5) ... ---------8<---------8<---------8<--------- >> If we want to strictly keep in sync with GCC, shouldn't we check the exact Automake version too? > > we pin the min version via AM_INIT_AUTOMAKE to 1.15.1. you're right we don't > currently pin the maximum, it's more through everyone agreeing to use that > version. if gcc et al had a macro to pin the automake version, we'd prob > leverage it too. > > pinning the versions in general is meant to keep generated noise/conflicts > down between devs working on these projects, and to make expectations more > obvious to users. > [...] > putting "we used xxx versions" into README The implementation is inconsistent. We pin the exact Autoconf version in order to minimise the noise/conflicts when regenerating those files, and state that a README has proven to be insufficient, but we do not pin the exact Automake version. Why not then? Regards, rdiez