You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The number of makefiles in this project is staggering, but in any case the issue I addressed in #525 for MSVC doesn't seem to be limited to MSVC. Seeing that there is a tommath_c89.h in the source tree, I was wondering if a more generalized approach for any C below C99 wouldn't be the better option at all. In the current draft pull request the header is pretty complete, but has preprocessor conditions which will make it fail on non-MSVC compilers.
Arguably it could be tested on other old compilers (ancient Watcom comes to mind) and the switching could be done based on checking against the standard version, e.g.:
#if (__STDC_VERSION__ < 199901L)
#include <tommath_c89.h> /* an extended version of the current one */
#else
#include <stdint.h>
#include <stdbool.h>
#endif
(or invert the condition order, I don't care)
Either way this would improve the robustness and have all compilers benefit from the C89 compatibility, not just builds done with that makefile where some sed command creates an illusion of compatibility by changing the source files prior to a build (something that in my book is a big no no when building third-party code).
I would also recommend renaming the makefile to GNUmakefile and then consolidating its contents. E.g. for the assignment to OBJECTS it could use something akin to what the pre_gen (amalgamation) target has:
Rationale: if you already have a special makefile for GNU make it makes sense to make this explicit and limit its scope to GNU make. A makefile by the name GNUmakefile will be picked up first by GNU make (it has several names hardcoded), even before makefile. So it could in fact work to rename the current makefile to GNUmakefile then rename the current makefile.unix to makefile. The behavior should be the same, except that on BSD you no longer need to specify the file name.
For the most part when using GNU make I'd also recommend immediate assignments (:=) as opposed to lazy ones (=).
The text was updated successfully, but these errors were encountered:
assarbad
changed the title
tommath_C89.h versus other solutions for backward compatibility with <C99
tommath_c89.h versus other solutions for backward compatibility with <C99
Feb 13, 2022
The number of makefiles in this project is staggering, but in any case the issue I addressed in #525 for MSVC doesn't seem to be limited to MSVC. Seeing that there is a
tommath_c89.h
in the source tree, I was wondering if a more generalized approach for any C below C99 wouldn't be the better option at all. In the current draft pull request the header is pretty complete, but has preprocessor conditions which will make it fail on non-MSVC compilers.Arguably it could be tested on other old compilers (ancient Watcom comes to mind) and the switching could be done based on checking against the standard version, e.g.:
(or invert the condition order, I don't care)
Either way this would improve the robustness and have all compilers benefit from the C89 compatibility, not just builds done with that
makefile
where somesed
command creates an illusion of compatibility by changing the source files prior to a build (something that in my book is a big no no when building third-party code).I would also recommend renaming the
makefile
toGNUmakefile
and then consolidating its contents. E.g. for the assignment toOBJECTS
it could use something akin to what thepre_gen
(amalgamation) target has:Rationale: if you already have a special
makefile
for GNU make it makes sense to make this explicit and limit its scope to GNU make. A makefile by the nameGNUmakefile
will be picked up first by GNU make (it has several names hardcoded), even beforemakefile
. So it could in fact work to rename the currentmakefile
toGNUmakefile
then rename the currentmakefile.unix
tomakefile
. The behavior should be the same, except that on BSD you no longer need to specify the file name.For the most part when using GNU make I'd also recommend immediate assignments (
:=
) as opposed to lazy ones (=
).The text was updated successfully, but these errors were encountered: