There can be only one! (global.h)

[Peter Kümmel]

Thiago Macieira wrote:
> Alexander Neundorf wrote:
>> On Sunday 05 March 2006 14:59, Stephan Kulow wrote:
>>> On Sunday, 5. March 2006 11:46, Peter Kümmel wrote:
>>>> Hi there,
>>>>
>>>> while compiling khtml/kjs with mingw I've met a problem:
>>>>
>>>> There are THREE global.h files,
>>>>
>>>> kio/kio/global.h   <- svn
>>>> kjs/global.h   <- generated by the build process
>>>> kjsembed/kjsembed/global.h  <- svn
>>>>
>>>>
>>>> Because the naming is incorrect, these files are not
>>>> global they are only visible in their "include-space",
>>>> I propose the rename them.
>>> How so? kio/global.h is always included as such and the same for kjs -
>>> not sure about kjsembed, but it shouldn't matter at all.
>>>
>>> So where is your problem?
>> It works, but it's not nice. I already wanted to write basically the
>> same email. It only works if the include directories are given
>> correctly, otherwise it will include the wrong global.h and the
>> compiler will produce errors, but not that it didn't find the header.
>>
>> I'd suggest to rename them to something like kjs-global.h and
>> kio-global.h . Especially now that we have svn :-)
> 
> While that's a valid suggestion, I don't understand the reason behind it.
> 

When it is a must to include all global.h files with the correct
directory specifier then I think it is a good idea to break compiling
when you forget this specifier.


> #include <kio/global.h> will never clash with the KJS or KJSEmbed's 
> global.h. If you find somewhere it's doing #include "global.h", it's 
> probably best to change there.
> 

It has clashed with kjs/global.h until yesterday (cmake build) and there
were no warnings or errors. It was a pure coincidence that there is no
important stuff in kjs/global.h, and kio/global.h also does the job.

We should eliminate as much as possible coincidence because Murphy's
law is merciless.


> As for the other two global.h, it should work too. In the future, if we 
> move things around in SVN, we may end up with duplicate names too, so 
> it's important to support that from the start. 
> 

OK, that's a argument. But if you have a for instance several base.h
headers which all defines some classes for the specific library then
it is much more likely that you get a compiler error because of different
defined classes.

> The include paths are defined per directory, right? So what's the whole 
> problem?
> 

Now we have to search all files to find "global.h" (I've found 20 files),
a job which could be done by the compiler.

Why shouldn't we remove a traps we found and why shouldn't we be pedantic
much as possible so long as the change doesn't hurt too much.

I walked into this trap, and I thought "Hey if we rename all these
global.h file, nobody could ever trap again into it." Because of this
I think it is a problem, maybe not a very big one, but it costs me some
time and considerations.

So what's the whole problem renaming some files?

Peter