Just a comment. the OpenSSL build already depends on Perl and Perl already
has a "Make" of it's own .
That would at least relieve some of the problems with being dependent on
"lowest common denominator" features common to the various platform makes.

I'll admit, I have no idea whether the Perl variant of make is an
improvement or not, but at least it would remove one dependency and provide
the same features across platforms.

Peter




From:   Nathan Typanski <ntypan...@gmail.com>
To:     openssl-dev@openssl.org
Date:   15/08/2014 09:40 AM
Subject:        Re: Single-Makefile Build Experiment report
Sent by:        owner-openssl-...@openssl.org



On 08/14, Tim Hollebeek wrote:
> Have you considered moving to CMake?  It makes lots of the issues
> you discuss in the document just go away.  cmake should work on the
> vast majority of supported operating systems, if not all of them ...

Cmake has disadvantages. I haven't actually used it enough to comment
on what it's like to use, but I can link to a project that has:

<https://wiki.openoffice.org/wiki/Build_System_Analysis#CMake>

OpenOffice was trying to solve the recursive make problem in their
project, much like OpenSSL is attempting. They ultimately decided
against CMake and gave a good writeup of their reasoning.

There's also a nice debate at LWN.net about GNU Make/CMake and the
related tradeoffs.

<http://lwn.net/Articles/466137/>

Also, consider the scenario:

- I'm an embedded developer and I want to compile OpenSSL on my
  embedded system (or any platform that isn't my workstation). It
  doesn't have CMake, I can't get CMake on it or don't have the
  resources (or desire) to get CMake installed on the target platform.
- To solve this, I download OpenSSL on my workstation and tell CMake
  to generate a GNU Makefile for me. I copy the source over to the
  platform I want to build OpenSSL on.
- I do `./configure && make && make install` and pray.
- The build fails and dumps and unhelpful error message. I go digging
  into the generated Makefile looking for the build error and realize
  CMake has built absolute paths into everything.
- I go on the CMake wiki and read this:
  <
http://www.cmake.org/Wiki/CMake_FAQ#Why_does_CMake_use_full_paths.2C_or_can_I_copy_my_build_tree.3F
>
  where the answer is basically "no, you can't use CMake like that. Go
  install CMake on your embedded device, or figure out how the hell to
  cross-compile a CMake build".
- Researching cross-compiling CMake turns up this:
  <http://blog.beuc.net/posts/Cross-compiling_with_CMake/>
- I come complain on this mailing list because OpenSSL has rejected
  both GNU and UNIX-like standards in favor of this stupid "more
  advanced" build system.

Maybe I'm biased, but from what I've seen with projects using CMake,
CMake is only portable in the sense that KDE is portable: yes, if
you're willing to enforce complete buy-in from the
users/packagers/maintainers, people can build OpenSSL easily on more
than one system.

But from my eyes it doesn't look like a low-level, relatively tiny C
library has any good reason to switch to CMake.

        Nathan
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@openssl.org
Automated List Manager                           majord...@openssl.org



______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@openssl.org
Automated List Manager                           majord...@openssl.org

Reply via email to