Add distro maintainers as collaborators

[noloader]

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

[alonbl]

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.

[noloader]

@alonbl,

Initially I thought you will drop your proprietary build system ...

We use GNUmake to build the library. There's nothing proprietary about it.

I considered to help, now I understand that this is not something that going to be, no reason to waste time.

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.

[alonbl]

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.

[noloader]

@alonbl,

I can help if your roadmap is to switch ...

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.

I am unsure why you need both...

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 project(cryptopp, CXX). STRIP does not trim trailing whitespace (another bug), Cmake fails to set NDEBUG for release builds (we caught a CVE because of it), and Cmake does not provide a way to get a terminal for a test (a design bug). These are some of the more obvious problems; and the full list of Cmake problems is fairly long. I enumerated many of the reasons for folks who wanted to work on it; see CMake Removal on the wiki.

[Azer0s]

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.

[solvingj]

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://cpplang.now.sh to signup for the slack team.

[anonimal]

The problem is not the tool, it is how you use the tool.

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

Projects that use best practices are easy to maintain while these who prefer to re-invent the wheel are unlikely to meet requirements.

"Best practices" describe the state in an evolution of development. This sort of evolution almost always requires change. Nothing here is being re-invented.

all the whining and complaining

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.

[FloriansGit]

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:

• Let's split up the CMakeLists.txt into shell scripts, CMake toolchains and some helper CMake scripts
  • This would reduce the number of if and execute_process calls dramatically
  • It will get less likely to break one platform's build with a fix meant for another platform
• Dedicated build scripts that do the necessary CMake executable calls for building on supported platforms
  • This would "document" what is tested and would be easier to handle for CMake newbies
• Go for a more up-to-date version of CMake
  • Actually I would opt for the upcoming CMake version 3.10. Not only because my extensions to cmake_host_system_information are released with it, but also because it will take a while (4-6 month) to get all the re-work done and this version will then be equally new and old enough

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.

[noloader]

@FloriansGit,

And yes, I'm aware that this will initially reduce the number of supported 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 :)

[solvingj]

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:

• Some group who wishes to use and contribute, and might have users on both posix and windows
• Projects referencing this via git-submodule, building it as part of their own project, which uses CMake
• Occasional cases like our team, who wishes to create automated cross-platform build of this library

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.

[FloriansGit]

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.

[GamePad64]

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.
Because supporting CMakeLists.txt to build correctly in Windows (VS, VS-Clang, MSYS, MinGW32), Unix and Cross-compilation anvironment is hard. It is easier to maintain, then all of currently existing build systems together, though.

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:

• Visual Studio 2017 brought native CMake projects support with all the CMake features natively integrated into IDE. There is no way to use Makefile as a project description.
• Xcode has a nice generator for CMake. There is no way to use Makefile as a project description.
• CLion has native support for CMake projects. There are no other ways for creating CLion project.

Plain makefiles are really hard to use for real-world packaging:

• Ubuntu/Debian uses a third-party autotools script inside its debianization archive, which is rewritten every release. Not good. Also, debhelper has native CMake support using dh $@ --buildsystem=cmake.
• Fedora in its fc27 src.rpm contains an Autotools patch, maintained separately by Fedora developers.
• MSYS2 distribution used a custom CMakeLists.txt, maintained by MSYS2 package maintainers. Now it uses CMakeLists.txt from 5.6.5 upstream.
• Microsoft Vcpkg official package doesn't try to use the Visual Studio solution included into upstream. Neither it tries to use GNUmakefile. It uses CMakeLists.txt from 5.6.5 upstream.
• Conan packages all use CMakeLists.txt from 5.6.5 upstream.
  Packages: 1, 2.
  The one package that uses GNUmakefile just doesn't support Windows, so it is considered broken, sigh.
• Hunter package, linked from ECIES is deprecated weidai11/cryptopp#510 (comment) also uses CMakeLists.txt from 5.6.5 upstream.

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.
I think, that you should support CMake 3.5.

Reasons:

• It can be built with a compiler without C++11 support, so basically everywhere, where Crypto++ is supported.
• CMake 3.5 is available in Ubuntu since Ubuntu 14.04 (in a package called cmake3)
• CMake 3.6 is available in Debian Jessie with jessie-backports enabled.

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.