autoconf
[Top][All Lists]
Advanced

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]