Add cmake support and tests

[LonghronShen]

• Add cmake support and tests
• Refactor the project structures

TODO:

• Mock is not very handy for pure C part;

[Malvineous]

This is certainly a very substantial contribution! However I fear it is moving away from the "simple .h file" premise of the library, once you have to start adding multiple files to your project.

I don't want to turn down your contributions but I do think they unfortunately make the project a lot more complex. Your version certainly does things "the right way" where I have compromised to keep things in a single .h file. The original premise was that this single file should be all you need and it doesn't matter whether you are using CMake, GNU autotools, Visual Studio, waf, or anything else.

I don't think I can merge this into the project for this reason, however I don't think you should abandon this work either. Perhaps you would be willing to keep this alive as a fork? I would be happy to link to your fork in the main README, and users of the library can choose which version suits them better.

What do you think?

[LonghronShen]

Thank you for your reply! Your library is excellent and simple in use, which impressed me very much yesterday. Since I'm developing a C++ project based on CMake building system, I just forked the project and try to add some CMake support to it.
I must admit that the principle of "simple .h file" is very important and the multiple files structure will broke the promise.
But when I'm trying to digest these code, I think besides the header only mode, we also need a true statically or dynamically linked library version, inline everywhere may not be a good idea. And as for more platform support, the single file pattern will make this single file too large to maintain. Split the file into several parts based on platforms or other aspects will make life simpler and easier. We still have the only entrypoint, the cfgpath.h, now it is a surrogate header file for you to include the right implementation based on your platform. And using these header files does not requires any support of CMake or any other tools, just copy the include folder and #include <cfgpath/cfgpath.h>, and the header only mode is used by default, just like what it is before.
In principle, we can also let CMake automatically merge these header files into one file, just as what it was before, or I can do it myself. There is not any functionally difference between the single header structure or multiple header files one. If this is the option, I can switch back to the single header structure.
As for the second option, hard fork the project and show the link in your repository, it is also a good idea, which suits different needs. But the cons are still there: I will add more platforms into the project, and contributing back to your repository may be more difficult.
So which way do you prefer?
Thanks again.

[Malvineous]

It is a difficult question, because your suggestions are definitely the better way to do it - easier to manage, cleaner code, etc. but the problem is the reason I started this project was that there are other libraries that do this but they are too large and complicated for small projects - I needed something simple that could work for small programs.

When you start mentioning static/dynamic libraries instead of inline, I think you have reached the point where your project is too large for what cfgpath originally intended. I had assumed that once a project got to this size, it would switch to one of the other libraries available (e.g. GTK, Qt, etc.) However these libraries are very large, so if you think there is still room for something in between cfgpath and GTK (for example), I think a fork is probably better. I don't see it as a problem having different versions available, as long as it is clear what the differences are. I am happy to link to your fork and explain which version is best for what type of project, and if you did the same then I think it would be more useful as people will then have a choice depending on their needs.

It is true that this will mean more effort adding more platforms, however as both projects are open source and will hopefully share the same licence, someone else may choose to port code across between the two libraries if they need it. Or, supporting more platforms might make your version more appealing to some people.

I am quite happy for you to maintain a fork and we can cooperate where needed. I think what you want to do is different enough that both versions would serve useful purposes.