-
Notifications
You must be signed in to change notification settings - Fork 99
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Switch to CMake #43
Comments
I'm interested... I'm not sure what's best as a baseline. Is there any sense in having both? |
Yes. You can do both. |
@imneme The benefit of CMake is improved portability (meaning, going to different systems and compilers). Your makefile probably won't work for Visual Studio users whereas CMake will work there as well. However, a makefile has features of its own. You can do low-level optimizations to the build with a makefile that are hard to do with CMake. |
You can have both, but in my opinion, it is not meaningful to have both at the same time. #44 should be a nice place to start off. If you want, I can do a couple of more modifications to the folder structure to make it even better. EDIT. Both @lemire and I wrote at the same time, aparently. Sorry for a similar post from my side :) |
Certainly, the Makefile is no longer needed generally once you have a CMake, and having both introduces redundancy and thus maintenance costs... However, there are things that are easy to do with a hand-tuned Makefile that are hard to do with CMake. CMake tends to produce rather dumb builds that are slow. |
I tend to disagree with you on this. However, I need to mention that I am not a C/C++ expert with a lot of experience in C++, CMake and Makefiles. I have not personally experienced the dumb and slow Makefiles generated by CMake, but I have read about and experienced performance improvements obtained when using Ninja instead of Makefiles in CMake. That being said, since this library is a header-only library, I doubt we could observe any penalty when switching to CMake. In any case, I am not the owner of the repo, and the repo can certainly have both at the same time. All I can do is to improve my first version of CMake with more of the suggested steps mentioned in Effective CMake. |
Dropping the Makefile entirely would be fine in case of this project. Further comments to illustrate the points I was making... Responding to
You wrote
Let me give you an example. If you want to turn on LTO (link-time opti.), it is literally just 6 characters in a Makefile (add
So while I can keep in my head the LTO flag ( That's unavoidable. CMake abstracts away the configuration. So it is necessarily higher level... and, as we know, all abstractions are leaky. At some point, for some corner cases, CMake is going to make you pay for the abstraction. There is no free lunch.
That's correct, I think. A hand-tuned Makefile can match a Ninja build, but if you are using CMake to generate a Makefile, you are getting something dumb. Going with Ninja might be a workaround. |
Wow. Thank you, @lemire, for your time in writing such a detailed answer to explain your view. As I said, I have not thus far had any situation where I need to use any of those features of CMake. So far, I have only used CMake as a dependency management tool --- defining targets and their dependencies (usage/consumption requirements). For most people (e.g., Effective CMake), this is how CMake should be used. The reason is that global variables such as Be it pcg-cpp or any other library for that matter, I think the most important thing in (sub-)projects are what the targets and their consumption requirements are. That's why I personally don't like Makefiles or CMake-based projects that define low-level compiler (e.g., |
I'm very much interested to rely on pcg-cpp. But at the moment it is quite hard to rely on it without precisely CMake support (and a regular) release interval. In fact, it would suffice to use CMake to install the headers and create a target which then contains the relevant paths. Without it, I guess that for me the only realistic way is to use git sub-module or so. But I must admit that I'm not strongly in favour of this. |
Access to a package configuration file for integration into CMake projects would be helpful: |
@SomethingOtherThanNull If someone wants to produce a CMake build with the requested configuration files as part of a pull request I will review it and make a recommendation. If nobody is willing to do the work, it may not happen. |
Hi, I don't understand the request for If you check the associated PR, #44, you should be able to see that Please correct me if I am wrong, or comment further on what is needed from |
@aytekinar I was responding to @SomethingOtherThanNull who felt that people had not provided package configuration. Sorry if my reply was confusing. |
@aytekinar I have edited my reply to make it more precise. |
I will email @imneme with a proposal. |
Thank you, @lemire, for clarification. I would appreciate your feedback, then, on my PR, which has the package configuration settings/lines in place. |
@aytekinar Given that the request came from @SomethingOtherThanNull, it would be best if they had a look. On my end of things, I am working on seeing how we can get your PR merged. |
Thank you very much on that part. When I skimmed, today, all the comments both here and in the PR, I noticed that you've always been very supportive of this PR. I also went back in time to check our discussions/threads regarding my (unkept) promise of contributing to simdjson/simdjson#180, which I will do by the end of this year (I will go through your fantastic project, check if there is still anything I can do to contribute there, and come up with some suggestions). Anyway, I will not clutter this space much about a different thread/project. |
So sorry for creating confusion. My statement was meant to be in support of providing CMake as an option. With that, a major benefit is the ability to have such configuration files that make adoption of the package easier. It was not intended to be commentary on the PR or anyones work. I’m just fullly in support of CMake as an option. Take a look at gRPC as an example of a package that provides multiple choices. Have a great day. |
I think that there is agreement among several of us on the benefits of CMake in this instance. We just need to make it happen. My comment above was unclear, sorry about that. I think I misunderstood what you were commenting on. |
I'm not averse to CMake, but given that PCG is an include-only header, I'm not sure what it really brings. The Makefiles in the repository are just sanity-check testing. Anyway, a pull request would be great. |
The main benefit of using CMake is to enable/facilitate the use of PCG in a portable way in C++ projects. The CMake configurations will tell the build systems where to find the header files, what language standard is used in PCG, etc. With this information, the build systems will then be able to call the compilers with the proper switches and compilation options. Even though a library is header-only, still these libraries contain certain requirements (e.g., define statements, language standards such as
#44 was/is the pull request opened to close this issue. |
Would you be interested in making a switch to cmake-based installation? For the project I am working on, I have started removing
Makefile
s and writingCMakeLists.txt
files toTo make the sample functions and tests work (enforcing C++11 features in a portable way), I guess you need a CMake version of at least 3.1.3 (dates back to Feb 12, 2015).
Once finished, the build, test, and install processes will be portable among systems that support CMake. Moreover, all the
*.cpp
files intest-high
directory will be removed, as they are simply compile definitions used onpcg-test.cpp
andpcg-test-noadvance.cpp
.If you are interested, I can make a PR as soon as I finish writing the CMake scripts.
The text was updated successfully, but these errors were encountered: