Can you made it more configurable? about printf HOT 9 CLOSED

I have added a pull

from printf.

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...

from printf.

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

from printf.

@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.

from printf.

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

from printf.

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.

from printf.

...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

from printf.

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...

from printf.

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.

from printf.