Re: Examples of current platforms/architectures where sizeof(void*) >

[James Kuyper]

On 9/11/21 5:06 AM, HorseyWorsey@the_stables.com wrote:
> On Fri, 10 Sep 2021 14:17:46 -0400
> James Kuyper <james...@alumni.caltech.edu> wrote:
...
>> MisterMule's original comment on September 8th was about the difficulty
>> of putting dependencies into a makefile. That implies the use of make,
>> which is the build system that's relevant. gcc -MD is not intended to
>> remove the need for make, it's intended for use with make.
>> The problem that it solves is simplifying the creation of the makefile.
>
> Well I just tried it with Clang on a small (1000 line) project. Manually
> written Makefile is 29 lines. Generated .d files end up at 1305 lines and it
> failed anyway because one of the .h files is auto generated. A complete waste
> of time as far as I can see.

If the generated .d files totalled 1305 lines, then your 29 line
Makefile almost certainly too short - it didn't include most of the
dependencies that gcc -MD identified. How hard would it have been to
manually create a makefile containing all of those dependencies? If you
cared about them (which you obviously don't), wouldn't you greatly
prefer having gcc -MD identify them?

[Michael S]

You forgot system headers and other non-user headers.
I just tested a file that I was working with few days ago.
a single #include <immintrin.h> caused 76 lines in .d

[David Brown]

You can use "gcc -MMD" to omit the system headers from the dependencies.

[James Kuyper]

On 9/11/21 4:16 PM, Michael S wrote:
> On Saturday, September 11, 2021 at 10:22:53 PM UTC+3, james...@alumni.caltech.edu wrote:
>> On 9/11/21 5:06 AM, HorseyWorsey@the_stables.com wrote:
>>> On Fri, 10 Sep 2021 14:17:46 -0400

...

>>> Well I just tried it with Clang on a small (1000 line) project. Manually
>>> written Makefile is 29 lines. Generated .d files end up at 1305 lines and it
>>> failed anyway because one of the .h files is auto generated. A complete waste
>>> of time as far as I can see.
>>
>> If the generated .d files totalled 1305 lines, then your 29 line
>> Makefile almost certainly too short - it didn't include most of the
>> dependencies that gcc -MD identified. How hard would it have been to
>> manually create a makefile containing all of those dependencies? If you
>> cared about them (which you obviously don't), wouldn't you greatly
>> prefer having gcc -MD identify them?
>
> You forgot system headers and other non-user headers.
> I just tested a file that I was working with few days ago.
> a single #include <immintrin.h> caused 76 lines in .d

In what sense do you think I forgot them? One of the strengths of this
approach is gcc -MD tracks down all dependencies, direct and indirect,
including dependencies on system headers and non-user headers.
And if, for some bizarre reason, you don't want your code that rebuilt
when system headers are changed, even though building of your code might
be affected by those changes, you can also instruct gcc to leave them out.

[Michael S]

On Monday, September 13, 2021 at 6:10:17 AM UTC+3, james...@alumni.caltech.edu wrote:
> On 9/11/21 4:16 PM, Michael S wrote:
> > On Saturday, September 11, 2021 at 10:22:53 PM UTC+3, james...@alumni.caltech.edu wrote:
> >> On 9/11/21 5:06 AM, HorseyWorsey@the_stables.com wrote:
> >>> On Fri, 10 Sep 2021 14:17:46 -0400
> ...
> >>> Well I just tried it with Clang on a small (1000 line) project. Manually
> >>> written Makefile is 29 lines. Generated .d files end up at 1305 lines and it
> >>> failed anyway because one of the .h files is auto generated. A complete waste
> >>> of time as far as I can see.
> >>
> >> If the generated .d files totalled 1305 lines, then your 29 line
> >> Makefile almost certainly too short - it didn't include most of the
> >> dependencies that gcc -MD identified. How hard would it have been to
> >> manually create a makefile containing all of those dependencies? If you
> >> cared about them (which you obviously don't), wouldn't you greatly
> >> prefer having gcc -MD identify them?
> >
> > You forgot system headers and other non-user headers.
> > I just tested a file that I was working with few days ago.
> > a single #include <immintrin.h> caused 76 lines in .d
> In what sense do you think I forgot them?

In a sense that after you take into account long lists of system headers in the .d files it becomes perfectly possible
that manually written 29-line makefile is fully sufficient.

> One of the strengths of this
> approach is gcc -MD tracks down all dependencies, direct and indirect,
> including dependencies on system headers and non-user headers.
> And if, for some bizarre reason, you don't want your code that rebuilt
> when system headers are changed, even though building of your code might
> be affected by those changes, you can also instruct gcc to leave them out.

You have a right to dislike it, but makefiles that don't take into account a possibility of such unlikely event
as meaningful change of system headers are *very* common in industry practice.

[David Brown]

A great many makefiles are written with manually written dependency
lists. In such cases, adding all the system headers is not only a huge
amount of work, but likely to be wrong - you have a good chance of
forgetting some of them, and if the code is moved to a different system
or uses a different compiler, the particular combination of include
files is going to be different.

And in pretty much every case, it does not matter in practice. You
might update your kernel headers, or version of gcc, and technically
that should force a rebuild for files that depend on the headers. But
in reality, your code is not going to depend on the things that actually
might change. If you write a file has "#include <stdio.h>" because it
uses "printf", that pulls in another 19 system headers (on my system,
tested with gcc -MD). No change in any of these is going to affect the
call to printf.

But if you are generating the dependencies automatically, there is
rarely harm in going all the way and including the system headers - the
compiler is going to have to read the files anyway, so checking their
timestamps is not going to involve more disk IO time. If you are using
the dependency files for other purposes - looking at them manually,
generating include graphs, documentation, etc., then it can be
convenient to skip the standard include files.

[James Kuyper]

On 9/13/21 3:54 AM, Michael S wrote:
> On Monday, September 13, 2021 at 6:10:17 AM UTC+3, james...@alumni.caltech.edu wrote:
>> On 9/11/21 4:16 PM, Michael S wrote:

...

>>> You forgot system headers and other non-user headers.
>>> I just tested a file that I was working with few days ago.
>>> a single #include <immintrin.h> caused 76 lines in .d
>> In what sense do you think I forgot them?
>
> In a sense that after you take into account long lists of system headers in the .d files it becomes perfectly possible
> that manually written 29-line makefile is fully sufficient.

I knew full well that those headers were going to be included, and in
fact, wanted them to be included, so it's not a matter of me forgetting
something. Without all of those files being included in the dependencies
lists, it is not fully sufficient.

>> One of the strengths of this
>> approach is gcc -MD tracks down all dependencies, direct and indirect,
>> including dependencies on system headers and non-user headers.
>> And if, for some bizarre reason, you don't want your code that rebuilt
>> when system headers are changed, even though building of your code might
>> be affected by those changes, you can also instruct gcc to leave them out.
>
> You have a right to dislike it, but makefiles that don't take into account a possibility of such unlikely event
> as meaningful change of system headers are *very* common in industry practice.

I can understand that, if you had to rely upon manually generated
dependency lists. However, it's trivial to use gcc -MD to generate a
list of header dependencies that's not merely accurate, but also
comprehensive, complete, and always up-to-date, which is almost never
the case for manually created lists. The amount of time and effort you
spent while manually recording just the header dependencies listed in
that 29-line makefile would be far greater than the amount of time and
effort needed when using gcc -MD. That would be true even if you only
included a single such dependency.
Why in the world should you NOT include a real dependency just because
it will rarely ever be relevant, given how cheaply it can be included?
The only legitimate reason I can think of is if you need to be able to
build your project on a platform where you can't use gcc - and I fully
agree that this is a reasonable issue to consider.