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 _______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
