sba1
commented
11 months ago I'm not against integrating such change, however, have you tried to integrate the clib4 changes back to the original repository?
Also, the commits messages could be improved, i.e., the subject line should be not larger than 72 characters. Also, try to to "orthogonalize" your changes, i.e., the python3 change has nothing to do with the clib4 change. It would be nice to have this separated out (and possibly other stuff). All changes related to the PR could probably be squashed to a single one or few commits. It doesn't make much sense to change one thing in a commit just to change it to something different in another commit. The merge commit also seems to be misplaced here.
You don't have to create a new PR, just repush your reworked tree. This makes it easier to follow your changes.
@sba1 I am aware that this PR will be rejected. But, I would like to get your general opinion on the chance of you accepting a cleaned up version of this PR.
As you may or may not know, Andrea (afxgroup) forked a version of clib2. Collectively, we have decided to name it clib4. This PR would make it so that - at least for GCC 11 - the developer has the option of 3 c-runtime libraries: newlib, which continues to be the default, clib2 (sodero) and clib4 (afxgroup).
Version of GCC < 11 will not build clib4. But, I plan to put support for clib4 in for GCC 6 and 8.
This PR removes the EXP_CLIB2 option - now - clib4 is built along side clib2.
We would really like to this pulled into mainline ADTOOLS. I welcome and expect comments and requested improvements/changes to the changes. Of course, I will create a fresh branch with proper commits and as minimal as possible: to repeat, this is just so you can get a feel for the requested changes.
BTW: I have tested that I am able to build a cross compiler for GCC version 11, as well as a native compiler and - finally - a native-distribution in the form of an LHA file.
I have also tested that clib4 is not built for GCC versions that are not version 11. You will see from the makefile (native-build) that it is easy to add support for CLIB4 by simply adding to GNU-MAKE's filter function. Of course, it will require the changes to the GCC repo. Right now, only version 11 is supported.