On Jul 30, 2018, at 2:38 PM, Mauricio Ramirez <mauricio.ramirez@xxxxxxxxxx> 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.
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
https://lists.gnu.org/mailman/listinfo/autoconf
