Re: XCode cross platform maintainability issues
Re: XCode cross platform maintainability issues
- Subject: Re: XCode cross platform maintainability issues
- From: Andreas Grosam <email@hidden>
- Date: Thu, 29 Sep 2005 19:48:27 +0200
On 29.09.2005, at 15:58, Mike Bellerby wrote:
I have a String.h header file in a subdirectory of my project. When I try to do #include <string.h> it loads folder/String.h instead and gives a warning message '<x-tad-smaller>warning: mismatched case in filenames, wanted "string.h" but found "String.h"'</x-tad-smaller> that it is doing this.
It looks like, you defined a header search path like
my_path_to_source/folder
because you want to include the String.h file like:
// file other.h
#include <String.h>
Since there is also a system path where the compiler finds a "string.h" header, this is ambiguous in a file system which names are case insensitive. It selects the file in a user defined path first. Being platform independent also means that you need to take care of this.
Anyway, please notice, that the compiler may find any file which exist in the current specified search paths for this translation unit. Thus, it might happen, that you define another search path - because you want to use another library - and inadvertantly add another possible location for another header file named "String.h".
I cannot change the name of the header file as it is part of the cross platform section of the code. All other platforms handle this correctly and select the correct header e.g. Windows, Solaris and Linux.
Regardless of the name of a header file, the location of an included file is *always* possibly ambigous!
In order to get rid of almost all ambiguities I would recommend to carefully structure your project and set corresponding search paths, and **always** using relative paths in the include directive of your modules.
(just like qualified names)
Suppose you created a library "myLib", with an accompanying header file string.h.
In another project you want to use the library, and several of your modules include this header file string.h.
The header file may be located in /user/local/include/mylib/
Instead of defining a search path /user/local/include/mylib and including it via
#include <string.h>
in each of your modules of the your project, use the following approach:
In your project, set a search path to:
/user/local/include
and use this include directive in your source moduls/headers:
#include <mylib/string.h>
Then, even this wouldn't be ambigous anymore:
// file: mymodule.cpp
#include <myproject/config.h>
#include <myproject/string.h>
#include <mylib/string.h>
#include <otherlib/string.h>
#include <string.h> // std C header
You may use further "qualification" of file names if you have more sub-folders:
// file: myproject/config.h
#ifndef MYPROJECT_CONFIG_H
#define MYPROJECT_CONFIG_H
#ifdef MACOSX
#include <myproject/MacOS/config.h>
#else
#include <myproject/WIN32/config.h>
Caution: take care of propper guard macros for each file which shall be unique:
// file: myproject/MacOS/config.h
#ifndef MYPROJECT_MACOS_CONFIG_H
...
Furthermore, you should ensure that your library public header files do not depend on "other" search paths, and also that include directives set in public headers are "robust" enough in order not to conflict with any search paths set when compiling a client module - which eventually would be harmful:
// file: libheader.h
#include <afolder/config.h>
When including the libheader.h file in one of your source modules, and if afolder/config.h can only be propperly selected by the compiler by adding another search path which depends somehow on the lib that has been compiled, this is bad programming style!
or
// file: libheader.h
#include <config.h>
In this case, the name "config.h" is just to general, and not "unique enough". This may make clients unable to compile unless you change your file names, or it may conflict with other libraries headers (and search paths) so that it will become impossible to compile your sources at all.
The problem seems to be caused by the -I directive for the hmap file, as when I manually invoke gcc without this directive the correct header file is selected.
I have looked through the documentation extensively and can find no way of turning this directive off.
Does anyone know of a way to do this?
Sorry, no idea how to disable this.
Andreas
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden