Hi Dan. Tim, John,
Thanks for your detailed response. It worked for me !
John, your response was the most helpful..I shall take
into account your insightful suggestions regarding
structuring of projects, I'm sure it would prove to be
very helpful.
Thanks again,
Iyer
>
> "John (Eljay) Love-Jensen" <eljay@xxxxxxxxx> wrote:
> 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 , or . 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 ?
>
>
>
> ---------------------------------
> Access over 1 million songs - Yahoo! Music
Unlimited.
____________________________________________________________________________________
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com
