Can you made it more configurable?

[mgiaco]

Hi,

On small targets I do not use Float, Long and I also do not need a big buffer size. Can you made the code more configurable. I want to use the source as submodule as it is without any changes if possible. So it would be gread if you can add this or something else which solves the problem

// buffer size used for printf (created on stack)
#ifndef PRINTF_BUFFER_SIZE
#define PRINTF_BUFFER_SIZE    128U
#endif

// ntoa conversion buffer size, this must be big enough to hold one converted numeric number (created on stack)
#ifndef NTOA_BUFFER_SIZE
#define NTOA_BUFFER_SIZE      32U
#endif

// ftoa conversion buffer size, this must be big enough to hold one converted float number (created on stack)
#ifndef FTOA_BUFFER_SIZE
#define FTOA_BUFFER_SIZE      32U
#endif

// define this to support floating point (%f)
#ifndef PRINTF_NO_FLOAT_SUPPORT
#define PRINTF_FLOAT_SUPPORT
#endif

// define this to support long long types (%llu or %p)
#ifndef PRINTF_NO_LONG_LONG_SUPPORT
#define PRINTF_LONG_LONG_SUPPORT
#endif

so no I can use

#include "printf_config.h" 
#include "printf.h"

In the printf config i use

#define PRINTF_BUFFER_SIZE 32
#define PRINTF_NO_FLOAT_SUPPORT
#define PRINTF_NO_LONG_LONG_SUPPORT

many thanks
cheers
mathias

[mpaland]

My original intention was to make the main module configurable just inside the module.
But of course you are right, using the printf module as shared, versioned file/lib prohibits that.
A "print_cfg.h" somewhere in the include path seems to be the most reasonable solution.
I'll have a look...

[mgiaco]

Yes that would be a nice solution.
many thanks...

[mgiaco]

I have added a pull

[mpaland]

@mgiaco Thanx a lot for the PR! I had already created a modification.
Please see the print_cfg branch. If this is okay for you, I merge it into master and create a new version.
Pls test and give me feedback.

[mgiaco]

That dose not solve the problem. Now you have added a printf_cfg.h ... so when i use the lib as submodule or as subtree i need to modify the header so there is no real difference to the master. With my pull if I do not want to change anything everything works the same as in the master but if i would like to change some defines i can add them and leave all that in my main project. So your printf lib can be fetched and leaves untouched.

What do you dislike on my pull? I can change the name printf_config.h to printf_cfg.h if this is the problem. But please rethink your branch it does not solve the main problem on use the lib untouched

[mpaland]

It's just an idea right now, but I think it makes a big difference. As in many projects, config files need to be adjusted/customized according to the project. So the printf_cfg.h config file is normally not a versioned part of the library.
It's just here in the same folder for delivery.

In your project, you have a structure like
-- lib -- printf
..............- printf.c
..............- printf.h
........ -- other libs
-- cfg
......- printf_cfg.h
......- other_cfg.h

Make sure, that "cfg" is on your include path.
Now you can change the printf_cfg.h file without touching the lib.
You can even have (but not recommended) a default printf_cfg.h in the printf folder, when the cfg folder is above the lib folder in the include path.

[mgiaco]

...It's just here in the same folder for delivery, yes and that is the point...

Okay but you do not add this config file to the master branch - right? Then ever thing is great. In the master i see the config file only in the test or in an example folder.

Then it is possible to use the lib as submodule see here https://github.com/liebherrnenzing/stm32f4_canpie-fd/tree/master/source

thx

[mpaland]

All right, @mgiaco, now I see what you are after!

Yes, a config file in the project folder can cause problems here, but not if your include path has a cfg folder first. But honestly, I won't trust that.

Anyway, embedding foreign projects via links/references/submodules caused me a lot of trouble in the past. As you can see, printf is using the catch framework, so I copied the according file(s) and maintain them by myself. (update to actual catch 2.2.2 is coming)
So everything is nice, clean and cherrypicked.
Have a look in my old sqlitepp project. sqlite3 is directly bound to the project.
Here is an interesting article about (not) using submodules.

In your PR you rely on a compiler switch (PRINTF_CONFIG) which should enable config file inclusion. This switch needs to be defined as compiler parameter (-dPRINTF_CONFIG). That may cause problems in bigger projects if you have a lot of libs which use such technique. I'm trying to avoid that due to fail safe reasons.

Let me think about the options here...

[mgiaco]

Okay thanks I can live with my fork no problem ... I thought maybe you will add it back in any way.
A switch is better than no option to change anything :-)

Submodules are great but dangerous if you do not know what you're doing but I like it more than subtrees. I do have a lot of projects dealing with the same libs so therefore cherry picking is no option because then I have to do a lot of maintenance work on each project.