[Q] How to move forward with the generated header files?

[bertwesarg]

The generated header files always bugged me in this project. Are others also have the opinion, that this should be changed once and for all.

For example, most non-linux headers are out of date, after extern was added to function declarations. (Why an extern was added to function declarations is a mystery in its own to me though).

[cgzones]

Another problem is that the MakeHeader script does not update the headers if their content would not change.
But in case the timestamp of the source file being more recent than the timestamp of the header file, Make will always call the MakeHeader script, because it thinks the header is out of date.

[bertwesarg]

My intend was actually not to list the problems, there should be plenty of them and we are probably also all aware of these problems.

My intent was to gather opinions how to move forward with it. Expressing ideas and finding a consensus.

But thanks for your input anyway.

[natoscott]

The generated header files always bugged me in this project. Are others also have the opinion, that this should be changed once and for all.

It is certainly unusual, I agree, and I'm not against changing this. The main reason I'd not touched it was its clearly Hisham's preferred way of doing it, and we live in (dwindling) hope that maybe he might come back to htop development still.

Do you want to prepare a PR removing this? (it touches configure.ac too now) I think if we still haven't heard from Hisham soon, I vote we merge it right after the 3.0.0 release.

For example, most non-linux headers are out of date, after extern was added to function declarations. (Why an extern was added to function declarations is a mystery in its own to me though).

I can shed some light there - it's to do with the way gcc-10 and later default to "-fno-common": see commit dfd9279 and also https://gcc.gnu.org/gcc-10/porting_to.html

[bertwesarg]

For example, most non-linux headers are out of date, after extern was added to function declarations. (Why an extern was added to function declarations is a mystery in its own to me though).

I can shed some light there - it's to do with the way gcc-10 and later default to "-fno-common": see commit dfd9279 and also https://gcc.gnu.org/gcc-10/porting_to.html

I was only talking about functions and your references are only talking about variables.

[bertwesarg]

It is certainly unusual, I agree, and I'm not against changing this. The main reason I'd not touched it was its clearly Hisham's preferred way of doing it, and we live in (dwindling) hope that maybe he might come back to htop development still.

This is a valid concern. I can only hope, that removing it can attract more new developers.

Do you want to prepare a PR removing this? (it touches configure.ac too now) I think if we still haven't heard from Hisham soon, I vote we merge it right after the 3.0.0 release.

Can do.

[natoscott]

For example, most non-linux headers are out of date, after extern was added to function declarations. (Why an extern was added to function declarations is a mystery in its own to me though).

I can shed some light there - it's to do with the way gcc-10 and later default to "-fno-common": see commit dfd9279 and also https://gcc.gnu.org/gcc-10/porting_to.html

I was only talking about functions and your references are only talking about variables.

The -f-no-common applies to both variables and functions - failing to declare a function 'extern' in a header, and then including that header in multiple .c files results in multiple definitions of that function symbol. Subsequently, a link failure results.

[bertwesarg]

The -f-no-common applies to both variables and functions - failing to declare a function 'extern' in a header, and then including that header in multiple .c files results in multiple definitions of that function symbol. Subsequently, a link failure results.

How should a function declaration (int foo(void);) result in multiple function definitions (int foo(void) { return 42; })?

[zevweiss]

Personally, I'm squarely in the "remove it" camp (it's something that's gotten in my way every time I've hacked on htop locally), and since it sounds like Hisham's fine with things going in new directions here, I've gone ahead and opened #70 (a rebased version of a patch I've had sitting around locally for a while).

[natoscott]

The -f-no-common applies to both variables and functions - failing to declare a function 'extern' in a header, and then including that header in multiple .c files results in multiple definitions of that function symbol. Subsequently, a link failure results.

How should a function declaration (int foo(void);) result in multiple function definitions (int foo(void) { return 42; })?

Oh, meant to follow up on this - sorry. You are right @bertwesarg - I was thinking of inverse cases in shared libraries I've worked on in the past. This is a more complex situation (it is not for no reason that glibc and most system headers declare all functions as 'extern') - its not an issue for a standalone programs like htop though - we have no external linkage to functions declared here.

You can see some of the dso intricacies (and why attribute((common)) exists) here if interested in the wierd and whacky situations that arise around function declarations esp. now with -fno-common default: redis/redis#6900

[bertwesarg]

Sure, DSO is another beast, which we can happily ignore here.

redis/redis#6900

Here only function pointer variables are annotated with extern and __attribute__((common)), which also makes perfect sense.

[cgzones]

Auto-generated headers have been axed, see #70