Re: question about linker

On 07/12/2024 17:57, Bart wrote:

On 07/12/2024 16:17, David Brown wrote:

On 06/12/2024 23:26, Scott Lurndal wrote:

David Brown <david.brown@hesbynett.no> writes:

On 04/12/2024 23:48, Scott Lurndal wrote:

David Brown <david.brown@hesbynett.no> writes:

On 04/12/2024 17:55, Scott Lurndal wrote:

>

13 minutes by the wall clock, a bit over an hour
of CPU time.
>

>
Is that a "typical" build - or an atypical full clean build?
>

>
That was a build that touched a key header file, so maybe
85% full.  A full build adds a minute or two wall time.
>
A single source file build (for most source files) takes
about 28 seconds real, a large portion of that in make as it
figures out what to rebuild in a project with thousands
of source files and associated dependencies.

>
That sounds like your dependency handling in make is not ideal.  Store
your dependencies in individual files per source file, where both the
object file and the dependency file itself are dependent on the headers
used by the C file.  (The makefile should also have both the object file
and the dependency file dependent on the C source file.)

>
We use the standard makedepend support built into GCC.  It creates
a .d file for each source file that contains the dependencies
for that source file.

>
This is part of the makefile macro I use when generating dependency files:
>
        $(CCDEP) $(combined_cflags) $(2) $(3) -MM -MP \
                       -MT $(obj_dir)$(1)$$(@F:%.d=%.o) \
                       -MT $(dep_dir)$(1)$$(@F:%.o=%.o) \
                       -MF $$@ $$<
>
The point is that because the dependency files themselves are also targets in these dependency files, they don't need to be re-build unnecessarily.
>

>
Scale matters, (with two thousand+ source and header files, that's a lot
of 'access', 'read' and 'stat' system calls just to build the dependency
graph.   On NFS filesystems, which we use in most environments, the make
takes even more time.
>

>
If the issue is stat'ing the times for those files in order to check the dependencies, then I understand the bottleneck.  But I would not expect people to be sharing a source tree on NFS like that - it is certainly not the usual way of collaborating on projects.
>
Certainly it all sounds like you are doing something seriously inefficient.  You've only got ten times the number of files that I have, but massively slower update builds.

 This is to be lauded. Somebody actually questioning something whether build-times should be that long.
 Somebody other than me, that is.
 

There's a big difference, however.  I am asking Scott with a view to helping him get more efficient use out of the good tools he uses. (Scott's been doing this stuff pretty much since the dawn of time, but there's still a possibility that there are things he has not thought about.)
I am not suggesting he switches to crappy tools that might be faster, or boasting that my language is infinitely superior because it compiles faster, or whining about C in a C newsgroup, or making strawman arguments in an attempt to prove my position.
I am trying to see if there are ideas that could make his builds faster for his convenience - alternatively, I am trying to see if there are particular reasons for the extra time his builds take so that I can be sure to avoid the same circumstances in my own work.