[cfe-dev] RFC: Upcoming Build System Changes
David A. Greene
greened at obbligato.org
Tue Nov 1 13:18:09 PDT 2011
Óscar Fuentes <ofv at wanadoo.es> writes:
>>>> There are different overheads in different scenarios. The makefiles
>>>> get really poor utilization out of a 8 or 16-way machine because of
>>>> implicit synchronization between different sublibraries.
>>>
>>> BTW, adding explicit library dependencies will make the parallel builds
>>> worse,
>>
>> No they won't, for exactly the reason Chris stated.
>
> That's makes no sense. The automatic system we had generated an optimal
> dependency graph: no missing or unnecesary edges. You can't do better
> than than optimal, can you?
If you're using recursive make, it is by definitely not optimal.
> To think that no unnecesary dependencies will pop up on the build is
> delusional, unless you introduce some sort of automatic check. And once
> you have the automatic check, why not delegate to it the handling of the
> dependencies?
I never said they wouldn't show up. I said they're not worth worrying
about until you notice them. You notice them when you notice your build
isn't as parallel as it could be and that happens when the build takes
too long.
> As mentioned elsewhere, what we want is to know when a source code
> change creates a modification on the dependency graph, to decide if we
> are okay with that. Manually keeping up to date the dependency files is
> just an unnecessary bureaucratic burden.
I agree. Dependency files should not be necessary. But CMake uses such
files, doesn't it? What's the difference between that and Daniel's
solution? All things being equal, I prefer Daniel's solution because
CMake is just horrendous.
-Dave
More information about the cfe-dev
mailing list