Single-Makefile Build Experiment report

[Mike Bland]

As announced on the openssl-testing list, I'm happy to report early,
promising success in my Makefile refactoring experiment. Here's the
short link to the Google Doc containing all of the details:

http://goo.gl/yhvCno

Feedback welcome. Regardless of the ultimate judgment of the
experiment, I'm hoping to build upon this report and produce a
published article.

Questions:

- Do these results provide acceptable justification for adopting this
structure? (With the understanding that I may have to redo bits, of
course.)

- Provided the answer to the first question is "yes", should I do
whatever necessary to support BSD make, or will establishing GNU make
as a build requirement be acceptable?

Thanks,

Mike
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List opens...@openssl.org
Automated List Manager majo...@openssl.org

[Tim Hollebeek]

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

________________________________

This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.

[Mike Bland]

On Thu, Aug 14, 2014 at 4:32 PM, Tim Hollebeek <THoll...@trustwave.com> 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 ...

Nope; wasn't aware of CMake before to be honest. That's not to say I'd
dismiss it out of hand, but I was constraining myself to maintaining
compatibility with the existing toolchain, meaning Configure+{BSD,GNU}
make. I got a long way maintaining compatibility between BSD and GNU,
but ditched BSD near the end because of the absence of pattern rules.
(Then again, do we really need to build sources in different
directories with different CFLAGS, etc., or is that just an artifact
of organic growth?)

I will say that Geoff Thorpe and I discussed our ideas at length over
the phone a few weeks back, and in a nutshell, what I've done here
could serve as prologue to the complete overhaul of the build system
that he has in mind. Some of what he described, if I remember
correctly, sounds similar to what little I've just looked up about the
CMake, but I don't recall him referring to it specifically. (He's
pinged me to let me know he'll be available to comment on my report
next week.)

[Nathan Typanski]

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

[Peter Waltenberg]

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

[Salz, Rich]

> Just a comment. the OpenSSL build already depends on Perl and Perl already
> has a "Make" of it's own .

Ooh, that could be interesting. What's the perl make thing called? A web search for "perl make" was too voluminous...

/r$

--
Principal Security Engineer
Akamai Technologies, Cambridge MA
IM: rs...@jabber.me Twitter: RichSalz

[Nathan Typanski]

On 08/14, Salz, Rich wrote:
> > Just a comment. the OpenSSL build already depends on Perl and Perl already
> > has a "Make" of it's own .
>
> Ooh, that could be interesting. What's the perl make thing called?
> A web search for "perl make" was too voluminous...

Hm ... maybe some of my Google-fu can come in handy here.

- Looks like Perl has more than a few build systems. This web slideshow,
apparently from Bank Of America, is a comparison of build systems
written in Perl.

<http://preaction.github.io/Perl/Compare-Building-Modules.html>

- Module::Build apparently comes with Perl. I have absolutely no idea
whether it could be used to build C programs.

<http://perldoc.perl.org/Module/Build/Cookbook.html>

- Extutils::MakeMaker generates system-native (GNU Make for most POSIX
systems and NMake/DMake for Windows, according to the docs) Makefiles
from a `Makefile.PL` input:

<http://search.cpan.org/~bingos/ExtUtils-MakeMaker-6.98/lib/ExtUtils/MakeMaker.pm>

- If you're building C with it, there is Extutils::CBuilder which is
"used to build the C portions of Perl modules" but "not intended as a
general cross-platform interface to all your C building".

<http://search.cpan.org/~ambs/ExtUtils-CBuilder-0.280216/lib/ExtUtils/CBuilder.pm>

- I also found AutoPerl, which is apparently some sort of
syntax-compatible Automake implementation:

<http://autoperl.sourceforge.net/autoperl-man1.html>

- Config::AutoConf is an implementation of AutoConf macros in Perl.

<http://search.cpan.org/~ambs/Config-AutoConf-0.25/lib/Config/AutoConf.pm>

- Here's a slideshow someone made about building C modules using some of
the above tools:

<http://www.slideshare.net/hashashin/building-c-and-c-libraries-with-perl>

- Finally, the book "Intermediate Perl" has a chapter about "creating your
own Perl distribution" that includes some discussion of
ExtUtils::Makemaker and Module::Build.

<http://books.google.com/books?id=Q4EVfforC3UC&lpg=PA173&ots=eMQkUWWthZ&dq=perl%20build%20system&pg=PA173#v=onepage&q=perl%20build%20system&f=false>

I can't at all comment on whether these handle dependency resolution
as well as more traditional build systems. But Perl is second only to
C in its ubiquity on most platforms, so perhaps this isn't a horrible
idea ...

Nathan

[Tom Francis]

On Aug 14, 2014, at 9:20 PM, Salz, Rich <rs...@akamai.com> wrote:

>> Just a comment. the OpenSSL build already depends on Perl and Perl already
>> has a "Make" of it's own .
>

> Ooh, that could be interesting. What's the perl make thing called? A web search for "perl make" was too voluminous…

AFAIK, there’s just ExtUtils::MakeMaker, which is used to generate Makefiles from a script, and is heavily geared towards creating Makefiles to compile and install Perl modules.

> /r$
>
> --
> Principal Security Engineer
> Akamai Technologies, Cambridge MA
> IM: rs...@jabber.me Twitter: RichSalz
>

[Mike Bland]

If I may redirect the discussion here, interesting as it is... I've
got a refactoring of the build system in-hand, compatible with tools
already in use. As much as folks may be in support of adopting a new
build system entirely--which I agree, might be worthwhile--I'd like
feedback on the work I've already done, not the work we might do one
day with some completely different system.

Unless, that is, OpenSSL is ready to make the switch to a new build
system *right now*, in which case there'd be no point to moving
forward with adopting my changes. Somehow I don't see consensus on the
adoption of a new system happening anytime soon. In the interim I'd
appreciate it if the improvements I've made didn't stall on
interminable discussion of unmaterialized alternatives.

Thanks,

Mike

[Tim Hollebeek]

Mike, if you like, I can try to find some time next week for a phone call to answer questions and discuss our experience using CMake. I'm by no means an expert, but we've used it internally on a project and have come to believe it is completely awesome. Most open source projects are moving towards CMake-based build systems, and I see no reason why OpenSSL can't join that bandwagon.

-Tim

-----Original Message-----
From: owner-op...@openssl.org [mailto:owner-op...@openssl.org] On Behalf Of Mike Bland

Sent: Thursday, August 14, 2014 5:35 PM
To: opens...@openssl.org
Subject: Re: Single-Makefile Build Experiment report

On Thu, Aug 14, 2014 at 4:32 PM, Tim Hollebeek <THoll...@trustwave.com> 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 ...

Nope; wasn't aware of CMake before to be honest. That's not to say I'd dismiss it out of hand, but I was constraining myself to maintaining compatibility with the existing toolchain, meaning Configure+{BSD,GNU} make. I got a long way maintaining compatibility between BSD and GNU, but ditched BSD near the end because of the absence of pattern rules.
(Then again, do we really need to build sources in different directories with different CFLAGS, etc., or is that just an artifact of organic growth?)

I will say that Geoff Thorpe and I discussed our ideas at length over the phone a few weeks back, and in a nutshell, what I've done here could serve as prologue to the complete overhaul of the build system that he has in mind. Some of what he described, if I remember correctly, sounds similar to what little I've just looked up about the CMake, but I don't recall him referring to it specifically. (He's pinged me to let me know he'll be available to comment on my report next week.)

Mike

______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List opens...@openssl.org
Automated List Manager majo...@openssl.org

[Mike Bland]

I appreciate and may take you up on the offer, but it's still off-topic. ;-) I'd also be more inclined to accept after some feedback on my own offering.

Mike

[Nathan Typanski]

On 08/15, Mike Bland wrote:
> If I may redirect the discussion here, interesting as it is... I've
> got a refactoring of the build system in-hand, compatible with tools
> already in use. As much as folks may be in support of adopting a new
> build system entirely--which I agree, might be worthwhile--I'd like
> feedback on the work I've already done, not the work we might do one
> day with some completely different system.
>

Mike,

Sorry for contributing to the off-topic discussion. I'll try to make
up for it by posting some interesting data.

I wanted to know if your changes improved speed on my system, and ran
my own suite of benchmarks. I didn't actually bench incremental
builds, since I wasted all my time benching the full ones, but I put
together some charts and posted all the data along with them for
inspection.

<http://goo.gl/zXoniR>

If I'm correct in saying so, I think the right way to run the current
test suite is to do

$ make clean && make && make test

which means when I benchmarked `make test` with the current `master`
tree, I ran /usr/bin/time on both the `make` and `make test` commands,
appended both of those a file, and summed their output. If I was wrong
in how I did that, then the `make test` bench is wrong and you didn't
shave 3-4 seconds off the full build like I thought ;)

My system software/specs:

- Arch Linux w/ 3.16.0 kernel
- i7-2620M CPU. During the builds my clock speed averaged 3.2 GHz.
- 8GiB RAM
- Crucial MX100 SSD
- GCC compiler

Also, I read your article. The bits about `ssl/d1_both.c` not being
detected in the recursive make are scary. Ultimately it would probably
end up wasting time more than anything - if the person who merges the
code does a full `make clean` and runs the test suite before pulling
anything, they should catch that. But without a CI server, of course,
that's more time wasted trying to build broken code ...

Nathan

[Jan Just Keijser]

Nathan Typanski wrote:

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

FWIW: my experience with CMake is quite negative.
A few years ago I had to package some software for scientific grid
computing and the cmake based ones were always the hardest ones. If a
cmake build was working then it wasn't so bad but if you need to debug
it or if you need to cross-compile then it is (IMHO) an absolute nightmare.
I'd consider it a step backwards if openssl moved in the direction of
cmake.

JM2CW,

JJK / Jan Just Keijser

[Tim Hollebeek]

Ask and ye shall receive:

 

1.       You are 100% correct that recursive make is completely broken, and moving to a single makefile is a significant improvement even if something else is done in the medium/long term.

2.       If using GMake everywhere is practical, I think it’s a good idea.  I’ve worked on open source projects before that tried to support multiple makefile systems, and the results were so complicated as to be unmaintainable.  Portability of compilation is the responsibility of the build system, not the project build built.  This is essentially the same philosophy as CMake.  The code and even Makefiles shouldn’t care what platform they are on unless they REALLY need to.  Configure was the old way to do this, but IMHO it is showing its age.  I first used Configure/gmake like, what, 20 years ago?  And even then I had a custom precompiler to edit the inputs to take into account various stupidities of various platforms/architectures.

3.       FIPS confuses the crap out of our developers every time they try to build it correctly.  Any improvements you can make there will be greatly appreciated.

4.       I don’t know if you had problems with it, but I’ve had problems for years with the extensive use of symlinks to source code within the OpenSSL source.  If that could go away, I’d find the OpenSSL source much easier to understand and navigate.

 

Off-topic #1: your article on goto fail and heartbleed is awesome, and should be read in its entirety by everyone working on security critical software.

Off-topic #2: This would be a HUGE change, but I really wish OpenSSL would move towards something like Google Test to make it easier to write tests.

Off-topic #3: If there is a move towards OpenSSL using CMake, I and possibly a few people I know would probably be willing to help.

 

From: owner-op...@openssl.org [mailto:owner-op...@openssl.org] On Behalf Of Mike Bland
Sent: Friday, August 15, 2014 9:59 AM
To: opens...@openssl.org
Subject: RE: Single-Makefile Build Experiment report

 

I appreciate and may take you up on the offer, but it's still off-topic. ;-) I'd also be more inclined to accept after some feedback on my own offering.

Mike

On Aug 15, 2014 9:53 AM, "Tim Hollebeek" <THoll...@trustwave.com> wrote:

Mike, if you like, I can try to find some time next week for a phone call to answer questions and discuss our experience using CMake.  I'm by no means an expert, but we've used it internally on a project and have come to believe it is completely awesome.  Most open source projects are moving towards CMake-based build systems, and I see no reason why OpenSSL can't join that bandwagon.

-Tim

-----Original Message-----
From: owner-op...@openssl.org [mailto:owner-op...@openssl.org] On Behalf Of Mike Bland
Sent: Thursday, August 14, 2014 5:35 PM
To: opens...@openssl.org
Subject: Re: Single-Makefile Build Experiment report

On Thu, Aug 14, 2014 at 4:32 PM, Tim Hollebeek <THoll...@trustwave.com> 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 ...

Nope; wasn't aware of CMake before to be honest. That's not to say I'd dismiss it out of hand, but I was constraining myself to maintaining compatibility with the existing toolchain, meaning Configure+{BSD,GNU} make. I got a long way maintaining compatibility between BSD and GNU, but ditched BSD near the end because of the absence of pattern rules.
(Then again, do we really need to build sources in different directories with different CFLAGS, etc., or is that just an artifact of organic growth?)

I will say that Geoff Thorpe and I discussed our ideas at length over the phone a few weeks back, and in a nutshell, what I've done here could serve as prologue to the complete overhaul of the build system that he has in mind. Some of what he described, if I remember correctly, sounds similar to what little I've just looked up about the CMake, but I don't recall him referring to it specifically. (He's pinged me to let me know he'll be available to comment on my report next week.)

Mike

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       opens...@openssl.org
Automated List Manager                           majo...@openssl.org

________________________________

This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.

[Mike Bland]

Nathan and Tim,

Thanks much for helping refocus here. Responses inline.

On Fri, Aug 15, 2014 at 10:29 AM, Nathan Typanski <ntyp...@gmail.com> wrote:
> Mike,
>
> Sorry for contributing to the off-topic discussion. I'll try to make
> up for it by posting some interesting data.

No worries; I've certainly learned a lot from these tangents! Just
wanted to make sure the original signal didn't get lost in the midst.
:-)

> I wanted to know if your changes improved speed on my system, and ran
> my own suite of benchmarks. I didn't actually bench incremental
> builds, since I wasted all my time benching the full ones, but I put
> together some charts and posted all the data along with them for
> inspection.
>
> <http://goo.gl/zXoniR>
>
> If I'm correct in saying so, I think the right way to run the current
> test suite is to do
>
> $ make clean && make && make test
>
> which means when I benchmarked `make test` with the current `master`
> tree, I ran /usr/bin/time on both the `make` and `make test` commands,
> appended both of those a file, and summed their output. If I was wrong
> in how I did that, then the `make test` bench is wrong and you didn't
> shave 3-4 seconds off the full build like I thought ;)
>
> My system software/specs:
>
> - Arch Linux w/ 3.16.0 kernel
> - i7-2620M CPU. During the builds my clock speed averaged 3.2 GHz.
> - 8GiB RAM
> - Crucial MX100 SSD
> - GCC compiler

Thanks much for doing this! But I'm really surprised that you're
getting 16s full, nonparallel builds from the existing recursive make
structure, when my Mac Pro still clocks 65s. What am I missing here?

Also, I timed 'make clean && make' and 'make test/test_heartbeat' (and
not 'make test') separately on purpose; I'll explain further below.

> Also, I read your article. The bits about `ssl/d1_both.c` not being
> detected in the recursive make are scary. Ultimately it would probably
> end up wasting time more than anything - if the person who merges the
> code does a full `make clean` and runs the test suite before pulling
> anything, they should catch that. But without a CI server, of course,
> that's more time wasted trying to build broken code ...

All true. On the one hand, it seems that the single-Makefile
experiment is in pursuit of an ideal; but at the same time, I believe
this experiment demonstrates that the ideal is well within practical
reach. Every little bit of friction and surprising behavior we can
remove from the build process improves productivity by improving
efficiency and ensuring correctness--and it makes for a *much*
improved testing experience.

Speaking of which, that's why my final examples focused not on 'make
test', which runs the entire test suite, but 'make
test/test_heartbeat'. heartbeat_test.c, aside from being the test I
wrote, is currently the only example in the code of the type of unit
test I'm hoping to encourage: small, focused, and fast. It tests
specific functions/one specific feature, and runs quickly enough that
it maintains the flow of concentration while changing the code under
test, whereas most of the other tests drive end-to-end runs through
the command line interface. Those are indeed critical, but as proven,
don't catch everything; hence the push to improve unit test coverage.

The build time for this single test should prove representative of the
edit-compile-build-test cycle that I hope OpenSSL contributors will
begin to experience and adopt as a regular development habit. That
said, we can also work on improving the isolation of the rest of the
test suite so the full 'make test' will also benefit from maximum
parallelism. Right now, many tests expect to be run one-at-a-time
inside the test/ directory, which means that given enough parallelism,
the tests in their current state step on one another. (Yes, I've hit
this. :-)

On Fri, Aug 15, 2014 at 11:35 AM, Tim Hollebeek
<THoll...@trustwave.com> wrote:
> Ask and ye shall receive:
>
> 1. You are 100% correct that recursive make is completely broken, and
> moving to a single makefile is a significant improvement even if something
> else is done in the medium/long term.

That's what I'm shooting for: Before adopting a new system wholesale,
if we ever do, it'd be nice to improve the existing system such that
we have a reliable benchmark to compare it against. My particular
concern being the "if": There's no clear guarantee at this point that
anything else will be adopted, so it'd be nice to cleanup the system
we've already got, if possible; and I believe the experiment
demonstrates it's quite possible.

> 2. If using GMake everywhere is practical, I think it’s a good idea.
> I’ve worked on open source projects before that tried to support multiple
> makefile systems, and the results were so complicated as to be
> unmaintainable. Portability of compilation is the responsibility of the
> build system, not the project build built. This is essentially the same
> philosophy as CMake. The code and even Makefiles shouldn’t care what
> platform they are on unless they REALLY need to. Configure was the old way
> to do this, but IMHO it is showing its age. I first used Configure/gmake
> like, what, 20 years ago? And even then I had a custom precompiler to edit
> the inputs to take into account various stupidities of various
> platforms/architectures.

I'm strongly leaning on the side of GNU make advocacy here, for purely
practical reasons. I'm interested in hearing similarly practical
reasons for maintaining BSD (and other?) make compatibility, and how
the features that made the GNU make solution feasible can be expressed
in those other flavors. But even then, why not just pick one
ubiquitous flavor and be done with it? What's to be gained by
maintaining compatibility with other flavors when GNU is already
available on the same platforms?

> 3. FIPS confuses the crap out of our developers every time they try to
> build it correctly. Any improvements you can make there will be greatly
> appreciated.

I'm relatively clueless about FIPS, but I made sure that the "dummy"
FIPS builds I was doing maintained parity between the baseline and
experimental builds.

> 4. I don’t know if you had problems with it, but I’ve had problems for
> years with the extensive use of symlinks to source code within the OpenSSL
> source. If that could go away, I’d find the OpenSSL source much easier to
> understand and navigate.

Which symlinks? The only ones I've noticed are those build in
include/openssl and test/. Not that I'm attached to them, mind you,
but I haven't really been stymied by them--yet.

Incidentally, I've posted tips about using cscope and Exuberant Ctags
to navigate the source:
http://wiki.openssl.org/index.php/Testing_and_Development_Tools_and_Tips

> Off-topic #1: your article on goto fail and heartbleed is awesome, and
> should be read in its entirety by everyone working on security critical
> software.

Aww shucks, now you just got me blushing. :-P

> Off-topic #2: This would be a HUGE change, but I really wish OpenSSL would
> move towards something like Google Test to make it easier to write tests.

I chatted with Rich Salz briefly in-person about this, and he
indicated this might be feasible. And trust me, I'm the premier
champion of Saint Zhanyong, genius and original author of Google Test
(and its companion, Google Mock). :-)

In the short term, however, I introduced this "pseudo-xUnit pattern"
in heartbest_test.c, along with the test/testutil.{h,c} utilities, to
mimic much of the structure of Google Test without making GT and the
C++ compiler it requires it a build requirement--yet. The idea being,
we can still write lots of clearly-structured tests now, even absent a
framework, and do so in such a way that migration to a new framework
would prove relatively painless.

> Off-topic #3: If there is a move towards OpenSSL using CMake, I and possibly
> a few people I know would probably be willing to help.

Well, I'd certainly be willing to hear your thoughts on Cmake now.
I've also noted the concern of Nathan and JJK. Geoff Thorpe (and
possibly Ben Laurie, and maybe other core OpenSSL folks) would
probably like to jump in too, I'm sure. Hit me up offline, and maybe
we can set up a Hangout or something for next week.

[Nathan Typanski]

On 08/15, Mike Bland wrote:

> Thanks much for doing this! But I'm really surprised that you're
> getting 16s full, nonparallel builds from the existing recursive make
> structure, when my Mac Pro still clocks 65s. What am I missing here?

Oh. Crap.

$ git clone https://github.com/openssl/openssl.git
$ cd openssl
$ ./config
$ make clean
real 57.03
user 44.48
sys 5.29
/usr/bin/time -p make 44.48s user 5.29s system 87% cpu 57.040 total

*scratches head*

$ which gcc
/usr/lib/ccache/bin/gcc

I guess I'll re-run them later.

Nathan

[Nathan Typanski]

I forgot the only important timing command in the above sequence: the
actual build step. But, yes, I use ccache and it does ridiculous
things to build times. What looks like `gcc` from my end is just
copying cached builds out of RAM.

[Mike Bland]

Ah, ccache...all those years at the old company rotted so much of my memory. :-P

Still, it does look like the single-Makefile results are a win.

Mike

[Gisle Vanem]

"Mike Bland" <mbl...@acm.org> wrote:

> Still, it does look like the single-Makefile results are a win.

Yes, I agree. That's what I've done for years on Win32 (MSVC + MingW) with
this single GNU makefile:
http://www.watt-32.net/misc/openssl-windows.zip

Actually 2 files; Options.Windows and Makefile.Windows. With an
added apps/heartbleed.c test-program by Rob Stradling.

Use as e.g.:
make -f Makefile.Windows CC=gcc all

--gv