Add option 'PRINTF_ONLY_FCTPRINTF' to compile the library without functions that depend on putchar_.#206
Add option 'PRINTF_ONLY_FCTPRINTF' to compile the library without functions that depend on putchar_.#206Gizzzzmo wants to merge 1 commit intoeyalroz:developfrom
Conversation
6a3f773 to
fecbd92
Compare
|
This is a v-e-r-y extensive change, which I am not inclined to accept. Why do you believe it's not sufficient, to address the issue in #203, to support suppressing |
fecbd92 to
aec3cc0
Compare
When disabled, the main header doesn't expose printf_ and vprintf_, and these functins are not compiled into the library. Code is split into separate translation units for this purpose, and to allow linking with the full (static) library without supplying a definition for putchar_.
aec3cc0 to
dc3bff6
Compare
|
As I said in the issue discussion I find it more comfortable to use this way. Specifically what I mean are two scenarios:
Regarding the extent of the changes: And all the ~100 deletions in printf.c are just cut-and-pastes into the new files, meaning other than the file restructuring there are only about 30 new lines of code. Sure the restructuring itself isn't nothing, but it doesn't intrdocue as many changes as the diff stat would suggest. While reading through your PR I also realized that I forgot about the |
To resolve #203: When the CMake cache variables is enabled / when the equivalent define is set, the main header only exposes fctprintf and vfctprintf.
Only when the CMake cache variable is set are all other functions (those that depend on putchar_) not compiled into the library. This is to stay consistent with the way other options are currently handled, although I feel like this might be a design flaw, and it would be better to have printf.h unconditionally include the config header, which then would also need to be installed.
To separate the functionality cleanly, and to allow linking with the entire (static) library even when it wasn't built with the new flag without having to define putchar_, I split the functionality into two translation units. All code shared between the two TUs is in a new header internal.h.
This begs another question: Should I move the main header emtest.h into a separate include directory, and make only that one publicly accessible with target_include_directories?
Right now if a consumer of the libary adds the project as a subdirectory, then linking with the target allows them to include "printf/internal.h" which
(a) is probably undesirable, and
(b) when installing the library the header is not installed, so it can't be included
Incidentally this was already possible with the source file printf.c. Although I doubt any user will have done
#include <printf/printf.c>, it is technically a backwards-compatibility problem.