[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Make and subdir
From: |
Warren Young |
Subject: |
Re: Make and subdir |
Date: |
Mon, 30 Jul 2018 17:15:34 -0600 |
On Jul 30, 2018, at 2:38 PM, Mauricio Ramirez <address@hidden> wrote:
> This has worked great on RedHat 5, but when we're moving to Redhat 7, it
> fails when building mylibrary. It can't find some includes. If I go into
> the mylibrary directory, and do the make, it works just fine. Not
> understanding why I can no longer build the whole thing in one shot.
I’d suggest that you take this as an opportunity to move to a single top-level
Makefile and single top-level configuration system. It has significant
benefits, especially in today’s world of real hardware parallelism:
http://lcgapp.cern.ch/project/architecture/recursive_make.pdf
In that paper’s day, only high-end systems had multiple physical processor
cores, highly parallel storage subsystems, etc., so its advice held less weight
than today.
I regularly build my software with a 1.5x oversubscription on the cores. That
is, on an 8-core system, I use “make -j12”. A parallel make with that many
possible parallel build steps going on at once is far more reliable when there
is a single instance of make(1) controlling the whole build process.
I’ve wrapped that functionality into a command called mmake:
https://tangentsoft.com/pidp8i/doc/trunk/tools/mmake
That is in turn dependent on another script I wrote called corecount, which
hides away the local mechanism for counting the number of CPU cores:
https://tangentsoft.com/pidp8i/doc/trunk/tools/corecount
I welcome patches to that script that work on systems I haven’t encountered
yet. I fully expect that corecount incorrectly returns “1” all the time on
Solaris, for instance.
I’ve been using this pair of scripts long enough now that I reflexively type
“mmake” rather than “make.” I’ve also got Vim set to use mmake by default:
set makeprg=mmake
map <F5> :make run<CR>
map <F7> :make<CR>
map <F8> :make<CR>
map <F9> :make run<CR>
Those hot keys may be familiar to you if your work experience extends beyond
the Autotools world.
If the “Recursive Make Considered Harmful” argument bothers you, you may want
to read this paper next:
https://www.microsoft.com/en-us/research/publication/non-recursive-make-considered-harmful/
But realize, that paper isn’t telling you to keep using recursive Makefiles.
They’re reporting that they couldn’t get make to work for them at all at that
scale, so they replaced it entirely. If you’re going to do that, this is not
the right mailing list for you. :)
Non-recursive make has never been unmanageable at the scales I work at. My
largest Automake-managed project has 30 top-level build products, so it may be
of comparable scale to your project.