Hi!
We have this PR about fmt library:
https://github.com/FreeCAD/FreeCAD/pull/8077
I need fmt for another PR.
That PR is stop because we do not know which policy we have for Windows and new libraries.
In particular, we do not know if it is acceptable for Windows Developers and users, that libfmt is obtained via vcpkg instead of being part of the libpack.
I would appreciate that a developer with the necessary knowledge replies.
Is there a reason we can’t just add it to the LibPack? uwestoehr updates the pack from time to time, and it would be nice to have libfmt as a stopgap until we can use C++20 features.
I have answered to the corresponding PR right now. IMO the preferred way is to add it to the libpack. If we (i.e. Uwe 
) don’t want to prepare a new libpack right now then for developers on Windows it shouldn’t be too complicated to add the sources manually. We then could use the library in headers-only mode.
I also just responded there – wondering about using cMake’s fetch_content feature.
We can do this. However, I only took over to maintain the LibPack because nobody else did 
despite I am not super fit with libraries. Therefore I need your help:
Hold off a bit, I’m going to spool up a Windows VM and see if we can use a cMake solution. libfmt provides extensive string formatting capabilities to older versions of C++ – they were added to the standard in C++20: https://en.cppreference.com/w/cpp/utility/format
OK, but we agreed to stay with C++17 for the next major release: Making sure you're not a bot!
I am not so happy that we started to look recently too much to code formatting. We should especially not loose our release goal and when we want to stay with yearly releases (I think this is the consensus), we must now focus more on the code content rather than its formatting.
This does not mean this should not be done at all, I am speaking here from the perspective of the release manager. I would prefer formatting work at a beginning of a major development cycle.
Therefore allow me to ask if we can postpone this to the next major release cycle. If you disagree, what are the arguments of doing this work now (changing our set release framework)?
hence the use of libfmt as I understood it, otherwise they would use the standard implementations
I am not so happy that we started to look recently too much to code formatting. We should especially not loose our release goal and when we want to stay with yearly releases (I think this is the consensus), we must now focus more on the code content rather than its formatting.
this is not about formatting the code, but about formatting strings at runtime
This does not mean this should not be done at all, I am speaking here from the perspective of the release manager. I would prefer formatting work at a beginning of a major development cycle.
regarding actual code formatting, as I understood it the general sentiment is to at least wait until toponaming is merged to do one big sweep formatting all the repo and from then on new contributions shall use the established code format
As adrianinsaval notes, this is to add a more pleasant form of string formatting to C++17. C++20 includes this already, no library is needed.
C++20 includes this already, no library is needed
That’s not quite right. format is defined for C++20, but, like a number of other features, is not actually available.
Last I looked, format is experimental stage only in clang 15, which is just a couple of months old.
Other stuff like modules is not useable either. There are others.
So whilst C++ 20 offers a bunch of nice stuff, don’t expect all compilers to have implemented all features.
I agree that idea is an excellent solution, IFF we can’t get Windows users sorted via either libpack or vcpkg or some other.
The downside is it still adds libfmt to FreeCAD base (when module not available).
Module is clearly the preferable solution.
Thanks to all.
In my particular case it has to do with modernising old c style variadic templates that are used va macros to parameter packs. Lib fmt provides c printf style formatting. That is part of a pre-requisite for NotificationArea.
The library is the only possible support available now.
I am not sure I understand.
If the module is not available, a windows computer will download the library (both the source code and the static library). Because the CMake is prepared for a statically linked library, it will compile FC against this statically link library, right? So the source will not be added FC (definitely not in git). Or maybe the downloaded library will not have the static library?
You can try it out for yourself here:
https://github.com/FreeCAD/FreeCAD/pull/8508
It basically works, but is actually extremely annoying: even when I give it a tag, if the git fetch call fails, the build fails. That is to say: you can’t run cMake without an internet connection! I am looking for a way to make that more graceful, so that if it fails but you already have the source code for libfmt it works with what you have.
I see, thank you very much for giving it a go. I appreciate it.
If the library is statically linked, we just want it to be there during compilation time (we do not care about execution time).
I also read that there is a strong preference for making the library into the libpack (as opposed to installing via vcpkg).
With this in mind, wouldn’t it be “so easy” as to execute vcpkg, as in:
https://fmt.dev/latest/usage.html
grab the generated library and add it to the libpack, and then use the path of the library within the libpack in CMake?
I mean, does such approach have an obvious disadvantage?
Sorry for asking and not contributing here, I do not have windows available.
This entire topic sounds premature.
Does libfmt add any new capabilities that would support making compilation on Windows more difficult?
Or is it just the latest “Shiny Object”?
Gene
The main thing it provides is a much nicer string formatting, more like what we have in Python:
std::string s = fmt::format("The answer is {}.", 42);
Particularly for complex formatting, it definitely beats the old stream operators for readability. This type of formatting is part of the C++20 standard, but libfmt allows us to use it with compilers that do not yet fully support that standard.
OK, but why is this necessary right now? If we implement this, people want to use it, leading to lot of code changes. Therefore, I still think such things should be done at the beginning of a release cycle and I also don’t think it is that pressing to do this now, in the release cycles that is already in its 8th month.
I think we are all just pressing forward here – if you’d like to propose that we take a month or two to get a new release out I’m sure you’d find some receptive ears 
. You know better than anyone how much work that can be!
Sorry to be blunt. Yes, I need this now.
I have a whole feature written requiring it and I do not find it reasonable to postpone it sine die. We are not in a feature freeze.
Including the library does not necessarily mean a lot of code changes. I have minimal contained changes done for a very good reason (and upon advise from Werner during Christmas).
I understand that I am asking other Developers for help as I do not have Windows. But please, try to see it from the other side, we are trying hard that a change does not affect developers using Windows. It works fine in Linux. It works fine in MAC. It would most likely work fine in Windows via vcpkg. We just need some engagement from Windows Developers to ensure no one will suffer an unexpected disruption because of merging code requiring this library.
Uwe, I would highly appreciate your understanding and preferably active collaboration in this matter.
I am still not perfectly happy with the cMake solution, but I am working on improving it: I believe we should be able to move forward without asking Windows users to use vcpkg. I am having some trouble getting it to play nice with the CI, but I would appreciate a few non-Windows testers making sure it doesn’t break things for them. When you have a moment, please try to compile https://github.com/FreeCAD/FreeCAD/pull/8508 and let me know if it works.