Hi iyer,
Try this:
gcc -c -v -isystem $PWD/include hello.c
I strongly recommend that you do not use #include <> (with angle brackets), and instead use #include "" (with quotes).
The #include <> is used for system header files, such as <stdio.h>, or <sys/unistd.h>. Your project, whether the project headers themselves or headers as part of an SDK that you are making, should use #include "", since you are (probably) not making system headers. [See Note#1 below]
#define SOAPBOX
Also, as a matter of style (and as such, there is no compunction for you to use this convention... just a suggestion after having worked with C/C++ for 20 years on large projects), I recommend you use this directory & file layout for your project (let's assume your project is called DancingBear):
somewhere/DancingBear/
somewhere/DancingBear/Makefile
somewhere/DancingBear/hello.h
somewhere/DancingBear/src/hello.c
somewhere/DancingBear/src/retro.h
somewhere/DancingBear/hello.h
In your hello.c file, use #include "DancingBear/hello.h" for the header, and use #include "retro.h" for the header in the src directory.
The "somewhere" directory represents the root level directory that you're project(s) live. It may be that 100 projects all live at different root level "somewhere" directories, or it may be that the projects are all peers to one another.
The "DancingBear" directory represents your DancingBear SDK or application or what have you. It's where your PUBLIC header files reside.
The "Makefile" performs a build, and I suggest that it follows the common Makefile conventions. And that by default builds hello.c into "${BUILDROOT}/DancingBear/obj/hello.o", where ${BUILDROOT} defaults to "somewhere" if not specified, but can be overridden. That way you can have your source on a read only volume, and have the build deliverable (e.g., the executable or shared library or archive library) and intermediary byproduct files (such as object files) be created on the ${BUILDROOT} location.
Info on Makefile conventions: http://www.gnu.org/prep/standards/html_node/Makefile-Conventions.html
The "src" directory is where your PRIVATE source code and PRIVATE headers reside. Such as hello.c and retro.h (a private header file).
If you had platform specific files, they'd go in a subdirectory from src. For example:
somewhere/DancingBear/src/i386/fastblit.c
somewhere/DancingBear/src/PPC/fastblit.c
somewhere/DancingBear/src/SPARC/fastblit.c
Although for searching and editing sanity, I recommend prefixing (or suffixing) the platform specific source files with the particular platform as well:
somewhere/DancingBear/src/i386/i386fastblit.c
somewhere/DancingBear/src/PPC/PPCfastblit.c
somewhere/DancingBear/src/SPARC/SPARCfastblit.c
Another example, showing that "platform" can mean different things:
somewhere/DancingBear/src/X11/X11Gui.c
somewhere/DancingBear/src/Carbon/CarbonGui.c
somewhere/DancingBear/src/GDIPlus/GDIPlusGui.c
Consumers of your DancingBear project (if it is an SDK) would specify the DancingBear public headers like #include "DancingBear/hello.h".
#undef SOAPBOX
HTH,
--Eljay
Note#1 - there are many SDKs that consider their own headers to be system header files. That presumption in many cases is debatable. For example, should NCurses (which I find awesomely cool) be pulled in via #include <ncurses.h>?
