Add distro maintainers as collaborators #1
Comments
|
Autools files and CMake are not officially supported, so use at your own
risk. The community is still expected to maintain them.
If not officially supported, how come anyone expect we use them?
Initially I thought you will drop your proprietary build system into a standard one, either cmake or autotools I considered to help, now I understand that this is not something that going to be, no reason to waste time.
|
We use GNUmake to build the library. There's nothing proprietary about it.
Well, suit yourself. You were one of the folks who complained the loudest. I'm sorry to hear you don't want to use it now that you've gotten what you wanted. If you don't want to waste your time with CMake, then why do you ask we waste our time with it? I'm happy to work Cmake with others to help the Crypto++ community, but I'm not sure its a good idea if its just a waste of time. Would you like me to cancel the collaborator invite? If the decision is final then its probably best to cancel it. |
|
On 5 November 2017 at 23:07, Jeffrey Walton ***@***.***> wrote:
We use GNUmake to build the library. There's nothing proprietary about it.
The problem is not the tool, it is how you use the tool.
I hoped you realized that by now.
There are standard, conventions and patterns you do not follow.
20 years ago people understood that it is HARD to implement CORRECT build
system using plain make.
People provided other tools, first was autotools and then other followed,
recently the cmake became popular.
This discussion only shows what already a well known fact...
Projects that use best practices are easy to maintain while these who
prefer to re-invent the wheel are unlikely to meet requirements.
The more standard a package is the easier is to adopt it into downstream.
Well, suit yourself. You were one of the folks who complained the loudest.
I'm sorry to hear you don't want to use it now that you've gotten what you
wanted.
I can help if your roadmap is to switch, I am unsure why you need both
autotools and cmake efforts, choose one, do it once do it well.
Build system is not a sideshow.
|
Well, now is your chance to lead Crypto++ into the future. You can work on Cmake and ignore the rest. I would add it back to the Crypto++ sources, but it has to be stable. Getting Cmake into a good state is a chronic problem for the program. The best I can tell from the postmortem analysis, the reasons were (1) Cmake is too buggy, (2) Cmake is too untested, and (3) I was too inexperienced with it. You can add a (4) if you like - nearly none of the Cmake proponents stepped up to help maintain it. Once the file list was created and checked-in most folks walked away.
That's easy. Our GNUmakefile works everywhere with minimal effort. It also configures the library to our specifications. Cmake has too many bugs to be a viable candidate for the platforms we support. The documentation also kind of sucks, so its hard to find answers when attempting to work a task or work around a bug. I'm kind of amazed your argue for a program as buggy as Cmake. I'm surprised Gentoo finds it meets requirements. Cmake still can't set our project to C++ via |
|
Thanks for making this repo...since I rely on cryptopp (it´s amazing), I´m really happy that there is a way for me to use it without workarounds. |
|
Thanks for making this repo indeed. To @alonbl and everyone else here, I invite u to come to the #cmake channel in the cpplang slack team where we can chat and try to get a working implementation going over the next few weeks. Some of us there will also be working on finishing a CMake build for Facebooks folly ‘library’ as well, so the timing is good. I will try to reach out to kitware staff and try to talk them into visiting at some point. Https:https://cpplang.now.sh to signup for the slack team. |
@alonbl This logic doesn't apply to every tool ever invented. For example: the square wheel. CMake's bugs, caveats, and anti-patterns are at times not easily resolved nor is the effort required to resolve them always worth the effort.
"Best practices" describe the state in an evolution of development. This sort of evolution almost always requires change. Nothing here is being re-invented.
It's interesting how @noloader and myself have been the only ones in recent history collaborating on cryptopp's CMake development. Issues were opened, PRs were opened, but no one else decided to contribute. |
|
Since my last contribution to the CMake part of cryptopp a few month ago I've done some thinking of what could be improved when we all could agree on the goals and working on this together:
And yes, I'm aware that this will initially reduce the number of supported platforms. But I think it would then have good basis to build on for adding more while maintaining the existing platforms. |
If the folks who use CMake are happy with it then I say go for it. You won't be working in a vacuum. @anonimal and I will keep an eye on things and provide suggestions and feedback. I'll even jump in when I can, like adding/changing files, bumping version numbers, etc. I would caution to select a CMake version that is contemporary. I would define "contemporary" in terms of a distro like Ubuntu 12 LTS. The LTS means "long term support", so you will encounter them in the field several years after Canonical support ends. Ubuntu 12 support is ending sometime this year, so you should plan on seeing it into 2019 or 2020. A good choice of CMake versions is whatever Ubuntu 12 provides. Forgive me if you already knew this. As for support back to CentOS 5 or Fedora 1, don't worry about it. We will handle it through the GNUmakefile. The GNUmake is very powerful and efficient. There's not much too it. We will also handle Autotools for distros that use it like Debian and Fedora. I also work closely with Debian packager and maintainer László Böszörményi (@gcsideal), so distro support is relatively easy for us. He tells us what he needs, and we make the changes. That's about as hard as it gets. I sent you a collaborator invite. Feel free to make changes, and don't worry about stepping on toes. I've already shown how bad a job I can do with CMake :) |
|
I don't use this library, so take my input with a grain of salt. I think the goal of a supported CMake build file in this project wasn't really defined from what I saw, and so I think the recommendation is perhaps a bit misguided. Here's my point of view on the goal and approach: First, the core maintainers have indicated they will continue to keep supporting the Gnumake build system regardless of what happens with CMake. Whatever packaging process is in place for both Debian and Fedora can then continue unchanged, and need not bother about the CMake file. Thus, the primary goal of a CMake build file would seem to be to simplify and normalize the process of cloning and building the project for other community developers. There are a few specific scenarios:
Also, at least one secondary goal seems to be to address/fix many of the issues previously experienced and listed on the Wiki post. Many of these are very likely to be native to older cmake versions, and fixed in more recent versions. Based on these factors, I would suggest using a more modern CMake (contrary to @noloader's suggestion). The stability and security have been significantly enhanced in recent versions, both of which are stated priorities. Also, the syntax, logic, and maintainability is greatly improved in 3.2 or higher, and using the CMake Targets model is strongly advised by both Kitware and the community. Also, a more modern CMakeLists can be substantially shorter and more readable, which is highlighted as another ancillary goal by @FloriansGit comment. Regarding @FloriansGit's suggestion of shell scripts. I also disagree with that suggestion, as it adds another layer of indirection for people trying to integrate with this project from outside. A key value proposition of CMake for the community is that does provide a somewhat-consistent cross-platform API to the build process of a project. This API is then available for users, other CMake projects using git-submodules, and devops/automation tools like ours. When you insert proprietary scripts in front, in some ways you undermine the value of CMake to one or more workflows, and create more code in a different language which has to be understood and maintained. Again, my perspective is biased and certainly not the most important one, but I felt it might be valuable. |
|
Thanks for your comments. I would suggest a separate branch for drafting the rework I've suggested. It's probably better to just show where I like to go with this and then start discussing if this approach is worth exploring. |
|
Okay, I see.. It happened so, that me is who have made the initial commit of CMake support into the source tree, but quickly abandoned it. Why have I abandoned the CMake support right after the initial commit?Because the upstream developers have refused to ditch GNUmakefile, GNUmakefile-cross and Visual Studio solutions and use CMake instead of all of these. And I knew, that supporting these together will be ultra-hard, and CMake will be thrown away some day. Why I wanted to bring CMake support in the first place?The whole point was to provide support for modern distributions, package managers and IDEs. They all use CMake right now:
Plain makefiles are really hard to use for real-world packaging:
Well, you see... All new packagers adopt CMake, because it is much much easier to maintain and use. The single place I saw using GNUmakefile is Homebrew recipe, which was dated back to 2010 and haven't changed much since then. I strongly believe, that CMake removal instead of GNUmakefile was just a mistake, and its support will be returned into upstream soon. Which version to support?I think, you should remove CMake 2.8-3.1 support, because the paradigm has shifted during the version transition. Supporting 2.8 and 3.2 requires supporting two diferent approaches, and basically two different CMakeLists.txt. I have tried to make the CMakeLists.txt from upstream to be backward-compatible with CMake 2.8.6, and that was awful. Reasons:
So, old package recipes can be updated to CMake-based versions with ease, and they will be even more concise. But, as I said, the CMake support was intended to provide means for creating new packages for new distributions. And, as I told you before, all the new Crypto++ packages are already CMake-based. |
|
@GamePad64 I tried to modernize as much as possible the cmake build for crypto++. I fully support your analysis above. Please take a look at the latest version in the master branch and see if there are more enhancements that you think should be done. |
@alonbl, @Guozht, @Azer0s, @anonimal, @wildbiotiger, @UKMonkey, @UKMonkey, @Marc--Olivier, @Romain-Geissler-1A, @ZahlGraf, @nexussafe, @egorpugin, @HeinrichJanzing, @geoffbeier, @FloriansGit, @steady286, @zabulus, @morozovcookie, @GamePad64,
We moved our Autools files and CMake files to my GitHub. It allows them to be more "online" than the wiki and establish provenance by using a known GitHub. Using a separate GitHub also allows us to establish a boundary so users implicitly know the files are not part of the library, but available if desired. Finally, this is the sort of administrivia WD prefers to avoid, so I don't want to ask WD for a repo in his GitHub (at the moment).
Autools files and CMake are not officially supported, so use at your own risk. The community is still expected to help maintain them. If the community can get them into a good state, then we can consider moving them into the library proper.
If you are a maintainer of a distro or package, then please ping me so I can invite you as a collaborator on this GitHub. You don't need to ask permission to make changes. Just fix the problems that surface. My email address is noloader, gmail account.
The text was updated successfully, but these errors were encountered: